* [Xenomai-core] nervous nmi-watchdog
@ 2006-05-23 20:21 Jan Kiszka
2006-06-05 16:35 ` Philippe Gerum
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kiszka @ 2006-05-23 20:21 UTC (permalink / raw)
To: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]
Hi,
I'm getting nmi alarms about latency being > 100 us on a dual P-III 1GHz
(with and without CONFIG_SMP) once I start the latency test tool. But
the must be false positive. Can someone comment on this trace:
> : *fn -109! 91.810 __ipipe_unstall_root+0x8 (default_idle+0x3f)
> :| fn -18 0.220 __ipipe_handle_irq+0xe (common_interrupt+0x18)
> :| fn -17 0.228 __ipipe_ack_system_irq+0x8 (__ipipe_handle_irq+0x7f)
> :| fn -17 0.191 __ipipe_dispatch_wired+0xb (__ipipe_handle_irq+0x8a)
> :| * fn -17 0.219 xnintr_clock_handler+0x8 (__ipipe_dispatch_wired+0x77)
> :| * fn -17 0.198 rthal_nmi_disarm+0x8 (xnintr_clock_handler+0xd)
> :| * fn -17 0.202 xnintr_irq_handler+0xb (xnintr_clock_handler+0x1d)
> :| * fn -16 0.197 xnpod_announce_tick+0x8 (xnintr_irq_handler+0x24)
> :| * fn -16 0.256 xntimer_do_tick_aperiodic+0xe (xnpod_announce_tick+0xf)
> :| * fn -16 0.203 xnthread_periodic_handler+0x8 (xntimer_do_tick_aperiodic+0x7c)
> :| * fn -16 0.590 xnpod_resume_thread+0xe (xnthread_periodic_handler+0x1c)
> :| * fn -15 0.315 rthal_nmi_arm+0xe (xntimer_do_tick_aperiodic+0x1ed)
> :| * (0x00) 0x000305fb -15 0.223 rthal_nmi_arm+0xb5 (xntimer_do_tick_aperiodic+0x1ed)
[This is an ipipe_trace_special, reporting the delay (~200 us = 100 us
period + 100 us nmi-trigger).]
> :| * fn -15 0.370 xnpod_schedule+0xe (xnintr_irq_handler+0x5f)
> :| * fn -14 0.694 __switch_to+0xe (xnpod_schedule+0x557)
> :| * fn -13 0.826 __ipipe_restore_pipeline_head+0x8 (xnpod_wait_thread_period+0x1a1)
> : fn -13 0.222 __ipipe_syscall_root+0x9 (system_call+0x20)
> : fn -12 0.235 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x55)
> : fn -12 0.223 hisyscall_event+0xe (__ipipe_dispatch_event+0x5e)
> : fn -12 0.188 __rt_task_wait_period+0xd (hisyscall_event+0x220)
> : fn -12 0.192 rt_task_wait_period+0x8 (__rt_task_wait_period+0x39)
> : fn -12 0.250 xnpod_wait_thread_period+0xe (rt_task_wait_period+0x32)
> :| * fn -11 0.270 xnpod_suspend_thread+0xb (xnpod_wait_thread_period+0x6b)
> :| * fn -11 0.342 xnpod_schedule+0xe (xnpod_suspend_thread+0xeb)
> :| * fn -11 0.584 __switch_to+0xe (xnpod_schedule+0x557)
> :| fn -10 0.264 __ipipe_walk_pipeline+0xe (__ipipe_handle_irq+0x178)
> :| fn -10 0.302 __ipipe_unstall_iret_root+0x8 (restore_raw+0x0)
> : fn -10 0.191 __ipipe_stall_root+0x8 (default_idle+0x33)
> : *fn -9+ 6.641 __ipipe_unstall_root+0x8 (default_idle+0x3f)
> :| fn -3 0.530 do_nmi+0xd (nmi_stack_correct+0x1d)
> :| fn -2+ 1.315 dummy_nmi_callback+0x8 (do_nmi+0x39)
> :| fn -1 0.384 notifier_call_chain+0xb (do_nmi+0x7b)
> :| fn 0 0.612 rthal_nmi_watchdog_tick+0xe (do_nmi+0x99)
> :| fn 0 0.373 rthal_latency_above_max+0x8 (rthal_nmi_watchdog_tick+0x21)
> <| freeze 0x00000064 0 1.060 rthal_latency_above_max+0x13 (rthal_nmi_watchdog_tick+0x21)
[And this happens less than 15 us after the arming.]
> | fn 1 0.628 __ipipe_handle_irq+0xe (common_interrupt+0x18)
> | fn 1 0.199 __ipipe_ack_common_irq+0xa (__ipipe_handle_irq+0xeb)
> | fn 1 0.242 ipipe_test_and_stall_pipeline_from+0x8 (__ipipe_ack_common_irq+0x17)
Is there something like spurious nmi? No real nmi-related problem is
reported otherwise by the kernel.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-05-23 20:21 [Xenomai-core] nervous nmi-watchdog Jan Kiszka
@ 2006-06-05 16:35 ` Philippe Gerum
2006-06-05 19:06 ` Gilles Chanteperdrix
0 siblings, 1 reply; 11+ messages in thread
From: Philippe Gerum @ 2006-06-05 16:35 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
Jan Kiszka wrote:
> Hi,
>
> I'm getting nmi alarms about latency being > 100 us on a dual P-III 1GHz
> (with and without CONFIG_SMP) once I start the latency test tool. But
> the must be false positive. Can someone comment on this trace:
>
Issue confirmed here, on a dual 750 Mhz PIII Celeron. Starting the
latency test, the NMI watchdog pulls the break on cpu #0 after a few us,
albeit rthal_nmi_arm() had been told to trigger the NMI more than a
millisecond in the future (likely the HTICK emulation + 100 us NMI
threshold).
Running a UP + LAPIC enabled kernel on the same hw did not trigger the
spurious NMI, so I'd bet that the issue is SMP related, and not
hw/perfctr related.
--
Philippe.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-06-05 16:35 ` Philippe Gerum
@ 2006-06-05 19:06 ` Gilles Chanteperdrix
2006-06-05 19:15 ` Philippe Gerum
0 siblings, 1 reply; 11+ messages in thread
From: Gilles Chanteperdrix @ 2006-06-05 19:06 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Jan Kiszka, xenomai-core
Philippe Gerum wrote:
> Jan Kiszka wrote:
> > Hi,
> >
> > I'm getting nmi alarms about latency being > 100 us on a dual P-III 1GHz
> > (with and without CONFIG_SMP) once I start the latency test tool. But
> > the must be false positive. Can someone comment on this trace:
> >
>
> Issue confirmed here, on a dual 750 Mhz PIII Celeron. Starting the
> latency test, the NMI watchdog pulls the break on cpu #0 after a few us,
> albeit rthal_nmi_arm() had been told to trigger the NMI more than a
> millisecond in the future (likely the HTICK emulation + 100 us NMI
> threshold).
>
> Running a UP + LAPIC enabled kernel on the same hw did not trigger the
> spurious NMI, so I'd bet that the issue is SMP related, and not
> hw/perfctr related.
I never observe this on my dual PIII whereas I always have the NMI
watchdog option enabled. Are you running with or without the tracer ?
--
Gilles Chanteperdrix.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-06-05 19:06 ` Gilles Chanteperdrix
@ 2006-06-05 19:15 ` Philippe Gerum
2006-07-09 12:50 ` Gilles Chanteperdrix
0 siblings, 1 reply; 11+ messages in thread
From: Philippe Gerum @ 2006-06-05 19:15 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai-core
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > Jan Kiszka wrote:
> > > Hi,
> > >
> > > I'm getting nmi alarms about latency being > 100 us on a dual P-III 1GHz
> > > (with and without CONFIG_SMP) once I start the latency test tool. But
> > > the must be false positive. Can someone comment on this trace:
> > >
> >
> > Issue confirmed here, on a dual 750 Mhz PIII Celeron. Starting the
> > latency test, the NMI watchdog pulls the break on cpu #0 after a few us,
> > albeit rthal_nmi_arm() had been told to trigger the NMI more than a
> > millisecond in the future (likely the HTICK emulation + 100 us NMI
> > threshold).
> >
> > Running a UP + LAPIC enabled kernel on the same hw did not trigger the
> > spurious NMI, so I'd bet that the issue is SMP related, and not
> > hw/perfctr related.
>
> I never observe this on my dual PIII whereas I always have the NMI
> watchdog option enabled. Are you running with or without the tracer ?
>
w/o.
--
Philippe.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-06-05 19:15 ` Philippe Gerum
@ 2006-07-09 12:50 ` Gilles Chanteperdrix
2006-07-09 16:41 ` Philippe Gerum
0 siblings, 1 reply; 11+ messages in thread
From: Gilles Chanteperdrix @ 2006-07-09 12:50 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Jan Kiszka, xenomai-core
Philippe Gerum wrote:
> > I never observe this on my dual PIII whereas I always have the NMI
> > watchdog option enabled. Are you running with or without the tracer ?
> >
>
> w/o.
enabling xeno nmi watchdog whereas the nucleus module is built-in break
Linux nmi watchdog test. Maybe some setups are not done at Linux level
when this test fails, which could explain some weird behaviour
afterwards.
Do you have the message:
Testing NMI watchdog... CPU#0: NMI appears to be stuck (x->y)!
In Linux boot messages ?
--
Gilles Chanteperdrix.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-07-09 12:50 ` Gilles Chanteperdrix
@ 2006-07-09 16:41 ` Philippe Gerum
2006-07-09 16:56 ` Jan Kiszka
0 siblings, 1 reply; 11+ messages in thread
From: Philippe Gerum @ 2006-07-09 16:41 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai-core
On Sun, 2006-07-09 at 14:50 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > > I never observe this on my dual PIII whereas I always have the NMI
> > > watchdog option enabled. Are you running with or without the tracer ?
> > >
> >
> > w/o.
>
> enabling xeno nmi watchdog whereas the nucleus module is built-in break
> Linux nmi watchdog test. Maybe some setups are not done at Linux level
> when this test fails, which could explain some weird behaviour
> afterwards.
>
> Do you have the message:
> Testing NMI watchdog... CPU#0: NMI appears to be stuck (x->y)!
>
> In Linux boot messages ?
Nope. The NMI test looks ok.
Linux version 2.6.17-ipipe (rpm@xenomai.org) (gcc version 3.3.3 (Debian
20040321)) #1 SMP Tue Jul 11 03:17:18 CEST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fffd000 (usable)
BIOS-e820: 000000003fffd000 - 000000003ffff000 (ACPI data)
BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f6e80
On node 0 totalpages: 262141
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 225280 pages, LIFO batch:31
HighMem zone: 32765 pages, LIFO batch:7
DMI 2.0 present.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #1 6:8 APIC version 17
Processor #0 6:8 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
Built 1 zonelists
Kernel command line: root=/dev/hdc1 ro nmi_watchdog=1 vga=1 console=tty0
console=ttyS0,115200
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 751.749 MHz processor.
Using tsc for high-res timesource
I-pipe 1.3-07: pipeline enabled.
Console: colour VGA+ 80x50
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1032916k/1048564k available (2491k kernel code, 15100k reserved,
743k data, 272k init, 131060k highmem)
Checking if this processor honours the WP bit even in supervisor mode...
Ok.
Calibrating delay using timer specific routine.. 1505.65 BogoMIPS
(lpj=7528285)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 00000000
00000000 00000000
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 28k freed
CPU0: Intel Pentium III (Coppermine) stepping 03
Booting processor 1/0 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 1503.45 BogoMIPS
(lpj=7517293)
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000
00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 00000000
00000000 00000000
CPU1: Intel Pentium III (Coppermine) stepping 03
Total of 2 processors activated (3009.11 BogoMIPS).
ExtINT not setup in hardware but reported by MP table
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
migration_cost=1897
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xf0730, last bus=1
Setting up standard PCI resources
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI quirk: region e400-e43f claimed by PIIX4 ACPI
PCI quirk: region e800-e80f claimed by PIIX4 SMB
PIIX4 devres B PIO at 0290-0297
Boot video device is 0000:01:00.0
PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:04.0
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: e1800000-e2dfffff
PREFETCH window: e2f00000-e3ffffff
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 9, 2621440 bytes)
TCP bind hash table entries: 65536 (order: 8, 1310720 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
IA-32 Microcode Update Driver: v1.14 <tigran@domain.hid>
I-pipe: Domain Xenomai registered.
Xenomai: hal/x86 started.
Xenomai: real-time nucleus v2.2-rc3 (Engines Of Creation) loaded.
Xenomai: NMI watchdog started (threshold=100 us).
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@domain.hid).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Limiting direct PCI/PCI transfers.
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:04.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
Probing IDE interface ide1...
hdc: SAMSUNG SV2044D, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: max request size: 128KiB
hdc: 39862368 sectors (20409 MB) w/472KiB Cache, CHS=39546/16/63,
UDMA(33)
hdc: cache flushes not supported
hdc: hdc1 hdc2
usbmon: debugfs is not available
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
EISA: Probing bus 0 at eisa.0
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Testing NMI watchdog ... <6>input: AT Raw Set 2 keyboard
as /class/input/input0
OK.
Starting balanced_irq
Using IPI Shortcut mode
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 272k freed
EXT3 FS on hdc1, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:00:09.0: 3Com PCI 3c980C Python-T at f880e000.
0000:00:0a.0: 3Com PCI 3c980C Python-T at f8810000.
eth0: setting half-duplex.
netconsole: local port 6665
netconsole: interface eth0
netconsole: remote port 6666
netconsole: remote IP 192.168.0.8
netconsole: remote ethernet address 00:11:2f:0c:f1:ca
netconsole: local IP 192.168.0.7
netconsole: network logging started
--
Philippe.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-07-09 16:41 ` Philippe Gerum
@ 2006-07-09 16:56 ` Jan Kiszka
2006-07-09 17:07 ` Philippe Gerum
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kiszka @ 2006-07-09 16:56 UTC (permalink / raw)
To: rpm; +Cc: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 8679 bytes --]
Philippe Gerum wrote:
> On Sun, 2006-07-09 at 14:50 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>> > > I never observe this on my dual PIII whereas I always have the NMI
>> > > watchdog option enabled. Are you running with or without the tracer ?
>> > >
>> >
>> > w/o.
>>
>> enabling xeno nmi watchdog whereas the nucleus module is built-in break
>> Linux nmi watchdog test. Maybe some setups are not done at Linux level
>> when this test fails, which could explain some weird behaviour
>> afterwards.
>>
>> Do you have the message:
>> Testing NMI watchdog... CPU#0: NMI appears to be stuck (x->y)!
>>
>> In Linux boot messages ?
>
> Nope. The NMI test looks ok.
>
> Linux version 2.6.17-ipipe (rpm@xenomai.org) (gcc version 3.3.3 (Debian
> 20040321)) #1 SMP Tue Jul 11 03:17:18 CEST 2006
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000003fffd000 (usable)
> BIOS-e820: 000000003fffd000 - 000000003ffff000 (ACPI data)
> BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> 127MB HIGHMEM available.
> 896MB LOWMEM available.
> found SMP MP-table at 000f6e80
> On node 0 totalpages: 262141
> DMA zone: 4096 pages, LIFO batch:0
> Normal zone: 225280 pages, LIFO batch:31
> HighMem zone: 32765 pages, LIFO batch:7
> DMI 2.0 present.
> Intel MultiProcessor Specification v1.1
> Virtual Wire compatibility mode.
> OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
> Processor #1 6:8 APIC version 17
> Processor #0 6:8 APIC version 17
> I/O APIC #2 Version 17 at 0xFEC00000.
> Enabling APIC mode: Flat. Using 1 I/O APICs
> Processors: 2
> Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
> Built 1 zonelists
> Kernel command line: root=/dev/hdc1 ro nmi_watchdog=1 vga=1 console=tty0
> console=ttyS0,115200
> mapped APIC to ffffd000 (fee00000)
> mapped IOAPIC to ffffc000 (fec00000)
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Initializing CPU#0
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> Detected 751.749 MHz processor.
> Using tsc for high-res timesource
> I-pipe 1.3-07: pipeline enabled.
> Console: colour VGA+ 80x50
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1032916k/1048564k available (2491k kernel code, 15100k reserved,
> 743k data, 272k init, 131060k highmem)
> Checking if this processor honours the WP bit even in supervisor mode...
> Ok.
> Calibrating delay using timer specific routine.. 1505.65 BogoMIPS
> (lpj=7528285)
> Mount-cache hash table entries: 512
> CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000
> 00000000 00000000 00000000
> CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000
> 00000000 00000000 00000000
> CPU: L1 I cache: 16K, L1 D cache: 16K
> CPU: L2 cache: 256K
> CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 00000000
> 00000000 00000000
> Checking 'hlt' instruction... OK.
> Freeing SMP alternatives: 28k freed
> CPU0: Intel Pentium III (Coppermine) stepping 03
> Booting processor 1/0 eip 2000
> Initializing CPU#1
> Calibrating delay using timer specific routine.. 1503.45 BogoMIPS
> (lpj=7517293)
> CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000
> 00000000 00000000 00000000
> CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000
> 00000000 00000000 00000000
> CPU: L1 I cache: 16K, L1 D cache: 16K
> CPU: L2 cache: 256K
> CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 00000000
> 00000000 00000000
> CPU1: Intel Pentium III (Coppermine) stepping 03
> Total of 2 processors activated (3009.11 BogoMIPS).
> ExtINT not setup in hardware but reported by MP table
> ENABLING IO-APIC IRQs
> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
> checking TSC synchronization across 2 CPUs: passed.
> Brought up 2 CPUs
> migration_cost=1897
> NET: Registered protocol family 16
> EISA bus registered
> PCI: PCI BIOS revision 2.10 entry at 0xf0730, last bus=1
> Setting up standard PCI resources
> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> PCI: Probing PCI hardware
> PCI: Probing PCI hardware (bus 00)
> PCI quirk: region e400-e43f claimed by PIIX4 ACPI
> PCI quirk: region e800-e80f claimed by PIIX4 SMB
> PIIX4 devres B PIO at 0290-0297
> Boot video device is 0000:01:00.0
> PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:04.0
> PCI: Bridge: 0000:00:01.0
> IO window: disabled.
> MEM window: e1800000-e2dfffff
> PREFETCH window: e2f00000-e3ffffff
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 9, 2621440 bytes)
> TCP bind hash table entries: 65536 (order: 8, 1310720 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> IA-32 Microcode Update Driver: v1.14 <tigran@domain.hid>
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/x86 started.
> Xenomai: real-time nucleus v2.2-rc3 (Engines Of Creation) loaded.
> Xenomai: NMI watchdog started (threshold=100 us).
> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> highmem bounce pool size: 64 pages
> Installing knfsd (copyright (C) 1996 okir@domain.hid).
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> Limiting direct PCI/PCI transfers.
> Linux agpgart interface v0.101 (c) Dave Jones
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
> disabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
> loop: loaded (max 8 devices)
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> PIIX4: IDE controller at PCI slot 0000:00:04.1
> PIIX4: chipset revision 1
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
> Probing IDE interface ide0...
> Probing IDE interface ide1...
> hdc: SAMSUNG SV2044D, ATA DISK drive
> ide1 at 0x170-0x177,0x376 on irq 15
> hdc: max request size: 128KiB
> hdc: 39862368 sectors (20409 MB) w/472KiB Cache, CHS=39546/16/63,
> UDMA(33)
> hdc: cache flushes not supported
> hdc: hdc1 hdc2
> usbmon: debugfs is not available
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> mice: PS/2 mouse device common for all mice
> EISA: Probing bus 0 at eisa.0
> TCP bic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Testing NMI watchdog ... <6>input: AT Raw Set 2 keyboard
> as /class/input/input0
> OK.
> Starting balanced_irq
> Using IPI Shortcut mode
> kjournald starting. Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 272k freed
> EXT3 FS on hdc1, internal journal
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on hdc2, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> 0000:00:09.0: 3Com PCI 3c980C Python-T at f880e000.
> 0000:00:0a.0: 3Com PCI 3c980C Python-T at f8810000.
> eth0: setting half-duplex.
> netconsole: local port 6665
> netconsole: interface eth0
> netconsole: remote port 6666
> netconsole: remote IP 192.168.0.8
> netconsole: remote ethernet address 00:11:2f:0c:f1:ca
> netconsole: local IP 192.168.0.7
> netconsole: network logging started
>
>
I can confirm the failing NMI test here on my notebook with both nucleus
and native skin built into the kernel. I haven't seen false positive
NMIs yet, but the tracer is still on. Will switch off and re-check.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-07-09 16:56 ` Jan Kiszka
@ 2006-07-09 17:07 ` Philippe Gerum
2006-07-09 18:13 ` Jan Kiszka
2006-07-09 19:36 ` Gilles Chanteperdrix
0 siblings, 2 replies; 11+ messages in thread
From: Philippe Gerum @ 2006-07-09 17:07 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
On Sun, 2006-07-09 at 18:56 +0200, Jan Kiszka wrote:
> I can confirm the failing NMI test here on my notebook with both nucleus
> and native skin built into the kernel. I haven't seen false positive
> NMIs yet, but the tracer is still on. Will switch off and re-check.
FWIW, here, the false positive is raised immediately when starting the
latency test.
--
Philippe.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-07-09 17:07 ` Philippe Gerum
@ 2006-07-09 18:13 ` Jan Kiszka
2006-07-09 19:36 ` Gilles Chanteperdrix
1 sibling, 0 replies; 11+ messages in thread
From: Jan Kiszka @ 2006-07-09 18:13 UTC (permalink / raw)
To: rpm; +Cc: xenomai-core
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
Philippe Gerum wrote:
> On Sun, 2006-07-09 at 18:56 +0200, Jan Kiszka wrote:
>> I can confirm the failing NMI test here on my notebook with both nucleus
>> and native skin built into the kernel. I haven't seen false positive
>> NMIs yet, but the tracer is still on. Will switch off and re-check.
>
> FWIW, here, the false positive is raised immediately when starting the
> latency test.
>
Still no "luck" here, i.e. the watchdog only triggers when I reduce the
threshold. But I'm not on the box where I originally observed this
effect, and that one is out of reach for me now. Remains mysterious,
maybe chipset-dependent. Fortunately, it's only a debug feature.
Jan
PS: Hey, looks good for France. I do have to switch the "program" now. :)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-07-09 17:07 ` Philippe Gerum
2006-07-09 18:13 ` Jan Kiszka
@ 2006-07-09 19:36 ` Gilles Chanteperdrix
2006-07-10 17:28 ` Gilles Chanteperdrix
1 sibling, 1 reply; 11+ messages in thread
From: Gilles Chanteperdrix @ 2006-07-09 19:36 UTC (permalink / raw)
To: rpm; +Cc: Jan Kiszka, xenomai-core
[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 626 bytes --]
Philippe Gerum wrote:
> On Sun, 2006-07-09 at 18:56 +0200, Jan Kiszka wrote:
> > I can confirm the failing NMI test here on my notebook with both nucleus
> > and native skin built into the kernel. I haven't seen false positive
> > NMIs yet, but the tracer is still on. Will switch off and re-check.
>
> FWIW, here, the false positive is raised immediately when starting the
> latency test.
The attached patch attempt to workaround these early shots, count them,
and display them in /proc/xenomai/nmi_early_shots. Could you try it on
your box and see if the /proc display moves ?
--
Gilles Chanteperdrix.
[-- Attachment #2: xeno-nmi.diff --]
[-- Type: text/plain, Size: 2087 bytes --]
Index: ksrc/arch/i386/nmi.c
===================================================================
--- ksrc/arch/i386/nmi.c (revision 1316)
+++ ksrc/arch/i386/nmi.c (working copy)
@@ -61,6 +61,9 @@
unsigned long perfctr_msr;
unsigned long long next_linux_check;
unsigned int p4_cccr_val;
+
+ unsigned early_shots;
+ unsigned long long arm_date;
};
char __pad[SMP_CACHE_BYTES];
} rthal_nmi_wd_t ____cacheline_aligned;
@@ -108,8 +111,13 @@
rthal_nmi_wd_t *wd = &rthal_nmi_wds[cpu];
unsigned long long now;
- if (wd->armed)
+ if (wd->armed) {
+ if (rthal_rdtsc() - wd->arm_date < rthal_maxlat_tsc) {
+ ++wd->early_shots;
+ wd->next_linux_check = wd->arm_date + rthal_maxlat_tsc;
+ } else
rthal_nmi_emergency(regs);
+ }
now = rthal_rdtsc();
@@ -142,6 +150,27 @@
wrmsrl(wd->perfctr_msr, now - wd->next_linux_check);
}
+static int earlyshots_read_proc(char *page,
+ char **start,
+ off_t off, int count, int *eof, void *data)
+{
+ int i, len = 0;
+
+ for_each_online_cpu(i)
+ len += sprintf(page + len, "CPU#%d: %u\n",
+ i, rthal_nmi_wds[i].early_shots);
+ len -= off;
+ if (len <= off + count)
+ *eof = 1;
+ *start = page + off;
+ if (len > count)
+ len = count;
+ if (len < 0)
+ len = 0;
+
+ return len;
+}
+
int rthal_nmi_request(void (*emergency) (struct pt_regs *))
{
if (!nmi_active || !nmi_watchdog_tick)
@@ -180,6 +209,11 @@
rthal_linux_nmi_tick = nmi_watchdog_tick;
wmb();
nmi_watchdog_tick = &rthal_nmi_watchdog_tick;
+
+ __rthal_add_proc_leaf("nmi_early_shots",
+ &earlyshots_read_proc,
+ NULL, NULL, rthal_proc_root);
+
return 0;
}
@@ -188,6 +222,8 @@
if (!rthal_linux_nmi_tick)
return;
+ remove_proc_entry("nmi_early_shots", rthal_proc_root);
+
wrmsrl(rthal_nmi_perfctr_msr, 0 - RTHAL_CPU_FREQ);
touch_nmi_watchdog();
wmb();
@@ -215,6 +251,7 @@
rthal_local_irq_restore(flags);
}
+ wd->arm_date = rthal_rdtsc();
wrmsrl(wd->perfctr_msr, 0 - delay);
wmb();
wd->armed = 1;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-core] nervous nmi-watchdog
2006-07-09 19:36 ` Gilles Chanteperdrix
@ 2006-07-10 17:28 ` Gilles Chanteperdrix
0 siblings, 0 replies; 11+ messages in thread
From: Gilles Chanteperdrix @ 2006-07-10 17:28 UTC (permalink / raw)
To: rpm, Jan Kiszka, xenomai-core
[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 722 bytes --]
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Sun, 2006-07-09 at 18:56 +0200, Jan Kiszka wrote:
> > > I can confirm the failing NMI test here on my notebook with both nucleus
> > > and native skin built into the kernel. I haven't seen false positive
> > > NMIs yet, but the tracer is still on. Will switch off and re-check.
> >
> > FWIW, here, the false positive is raised immediately when starting the
> > latency test.
>
> The attached patch attempt to workaround these early shots, count them,
> and display them in /proc/xenomai/nmi_early_shots. Could you try it on
> your box and see if the /proc display moves ?
This patch should work better.
--
Gilles Chanteperdrix.
[-- Attachment #2: xeno-nmi.2.diff --]
[-- Type: text/plain, Size: 2129 bytes --]
Index: ksrc/arch/i386/nmi.c
===================================================================
--- ksrc/arch/i386/nmi.c (revision 1322)
+++ ksrc/arch/i386/nmi.c (working copy)
@@ -61,6 +61,9 @@
unsigned long perfctr_msr;
unsigned long long next_linux_check;
unsigned int p4_cccr_val;
+
+ unsigned early_shots;
+ unsigned long long tick_date;
};
char __pad[SMP_CACHE_BYTES];
} rthal_nmi_wd_t ____cacheline_aligned;
@@ -108,8 +111,13 @@
rthal_nmi_wd_t *wd = &rthal_nmi_wds[cpu];
unsigned long long now;
- if (wd->armed)
+ if (wd->armed) {
+ if (rthal_rdtsc() - wd->tick_date < rthal_maxlat_tsc) {
+ ++wd->early_shots;
+ wd->next_linux_check = wd->tick_date + rthal_maxlat_tsc;
+ } else
rthal_nmi_emergency(regs);
+ }
now = rthal_rdtsc();
@@ -142,6 +150,27 @@
wrmsrl(wd->perfctr_msr, now - wd->next_linux_check);
}
+static int earlyshots_read_proc(char *page,
+ char **start,
+ off_t off, int count, int *eof, void *data)
+{
+ int i, len = 0;
+
+ for_each_online_cpu(i)
+ len += sprintf(page + len, "CPU#%d: %u\n",
+ i, rthal_nmi_wds[i].early_shots);
+ len -= off;
+ if (len <= off + count)
+ *eof = 1;
+ *start = page + off;
+ if (len > count)
+ len = count;
+ if (len < 0)
+ len = 0;
+
+ return len;
+}
+
int rthal_nmi_request(void (*emergency) (struct pt_regs *))
{
if (!nmi_active || !nmi_watchdog_tick)
@@ -180,6 +209,11 @@
rthal_linux_nmi_tick = nmi_watchdog_tick;
wmb();
nmi_watchdog_tick = &rthal_nmi_watchdog_tick;
+
+ __rthal_add_proc_leaf("nmi_early_shots",
+ &earlyshots_read_proc,
+ NULL, NULL, rthal_proc_root);
+
return 0;
}
@@ -188,6 +222,8 @@
if (!rthal_linux_nmi_tick)
return;
+ remove_proc_entry("nmi_early_shots", rthal_proc_root);
+
wrmsrl(rthal_nmi_perfctr_msr, 0 - RTHAL_CPU_FREQ);
touch_nmi_watchdog();
wmb();
@@ -215,6 +251,8 @@
rthal_local_irq_restore(flags);
}
+ wd->tick_date = rthal_rdtsc() + (delay - rthal_maxlat_tsc);
+ wmb();
wrmsrl(wd->perfctr_msr, 0 - delay);
wmb();
wd->armed = 1;
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-07-10 17:28 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-23 20:21 [Xenomai-core] nervous nmi-watchdog Jan Kiszka
2006-06-05 16:35 ` Philippe Gerum
2006-06-05 19:06 ` Gilles Chanteperdrix
2006-06-05 19:15 ` Philippe Gerum
2006-07-09 12:50 ` Gilles Chanteperdrix
2006-07-09 16:41 ` Philippe Gerum
2006-07-09 16:56 ` Jan Kiszka
2006-07-09 17:07 ` Philippe Gerum
2006-07-09 18:13 ` Jan Kiszka
2006-07-09 19:36 ` Gilles Chanteperdrix
2006-07-10 17:28 ` Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.