* Heavy Clock-Drift after update from Kernel 2.4.9 to 2.4.19
@ 2002-08-05 21:03 Matthias Schniedermeyer
2002-08-05 22:26 ` Alan Cox
0 siblings, 1 reply; 9+ messages in thread
From: Matthias Schniedermeyer @ 2002-08-05 21:03 UTC (permalink / raw)
To: linux-kernel
#include <hallo.h>
I updated to 2.4.19 the day after it was released. Since then i have a
heavy clock-drift problem.
Some time there is no clock drift, other times there is heavy clock drift.
e.g. When i load a page with mozilla. The "rotating thing" spins
randomly fast/normal.
Or when i play a movie with "xine". Every few seconds the playing gets
faster and then back to normal.
With 2.4.9 the clock was "rock solid" for weeks.
A bit strange is that it seems to depend on load. Higher load seems to
cause less/none clock drift.
(e.g. when i compile something in background, the "rotating thing" in
mozilla doesn't spin to fast)
Hardware is a Dual-PIII-933Mhz. Kernel is configured as SMP.
Any more details needed?
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Heavy Clock-Drift after update from Kernel 2.4.9 to 2.4.19
2002-08-05 22:26 ` Alan Cox
@ 2002-08-05 22:17 ` Matthias Schniedermeyer
2002-08-06 8:14 ` 2.4.19-ac4 IRQ messup? Thomas Mierau
1 sibling, 0 replies; 9+ messages in thread
From: Matthias Schniedermeyer @ 2002-08-05 22:17 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Mon, Aug 05, 2002 at 11:26:23PM +0100, Alan Cox wrote:
> On Mon, 2002-08-05 at 22:03, Matthias Schniedermeyer wrote:
>
> > A bit strange is that it seems to depend on load. Higher load seems to
> > cause less/none clock drift.
> > (e.g. when i compile something in background, the "rotating thing" in
> > mozilla doesn't spin to fast)
> >
> > Hardware is a Dual-PIII-933Mhz. Kernel is configured as SMP.
> > Any more details needed?
>
> Can you grab /proc/interrupts every 5 minutes for an hour and send me
> the resulting file ?
I guessed wrong.
USB is the problem.
When i move my USB-Mouse i can see the seconds pass by. (Heavy moving
causes up to 2-3x higher "speed".)
Then maybe the USB-Keyboard problem is related. Every now and then a key
gets "stuck" and is repeated until i press another key. (Very annying
when you press "CTRL-n" in Mozilla for getting a new window. Personal
"record" was about 50 Windows)
(Currently i'm typing with the "normal" Keyboard)
But here is the wanted info
Record with this from another machine:
-- time.sh --
#!/bin/sh
while true
do
echo -n "Localtime: "
date
echo -n "Remotetime: "
ssh <remote> date \; cat /proc/interrupts
sleep 5m
done
-- End --
-- Begin --
Localtime: Mon Aug 5 23:18:03 CEST 2002
Remotetime: Mon Aug 5 23:18:34 CEST 2002
CPU0 CPU1
0: 687154 685272 IO-APIC-edge timer
1: 6478 6372 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 38180 38195 IO-APIC-edge serial
8: 8 4 IO-APIC-edge rtc
10: 90159 89996 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1946893 1959777 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2256667 2258749 IO-APIC-level eth0
24: 12 14 IO-APIC-level ide2, ide3
26: 31751 31651 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 14542 14420 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1083892 1083828
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:23:04 CEST 2002
Remotetime: Mon Aug 5 23:23:35 CEST 2002
CPU0 CPU1
0: 702302 700216 IO-APIC-edge timer
1: 6495 6394 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 38773 38794 IO-APIC-edge serial
8: 8 4 IO-APIC-edge rtc
10: 90159 89996 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1951998 1964779 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2288054 2292385 IO-APIC-level eth0
24: 12 14 IO-APIC-level ide2, ide3
26: 32160 32065 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 14574 14452 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1113987 1113923
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:28:05 CEST 2002
Remotetime: Mon Aug 5 23:28:36 CEST 2002
CPU0 CPU1
0: 717649 714961 IO-APIC-edge timer
1: 6547 6455 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 39386 39373 IO-APIC-edge serial
8: 8 4 IO-APIC-edge rtc
10: 90159 89996 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1958804 1971693 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2312661 2316329 IO-APIC-level eth0
24: 12 14 IO-APIC-level ide2, ide3
26: 33205 33106 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 14614 14489 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1144083 1144018
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:33:06 CEST 2002
Remotetime: Mon Aug 5 23:33:54 CEST 2002
CPU0 CPU1
0: 735216 732129 IO-APIC-edge timer
1: 6777 6666 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 40052 40079 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 91593 91536 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1960578 1973582 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2319176 2322831 IO-APIC-level eth0
24: 12 14 IO-APIC-level ide2, ide3
26: 33246 33164 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 14870 14751 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1174177 1174113
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:38:07 CEST 2002
Remotetime: Mon Aug 5 23:40:22 CEST 2002
CPU0 CPU1
0: 754736 751466 IO-APIC-edge timer
1: 6967 6890 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 40846 40825 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 94361 94214 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1963168 1976115 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2627805 2631421 IO-APIC-level eth0
24: 17 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 15005 14900 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1204272 1204208
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:43:08 CEST 2002
Remotetime: Mon Aug 5 23:47:07 CEST 2002
CPU0 CPU1
0: 774954 771719 IO-APIC-edge timer
1: 6974 6899 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 41592 41679 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 97489 97273 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1963168 1976115 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2633541 2637118 IO-APIC-level eth0
24: 18 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 15124 15015 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1234366 1234302
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:48:09 CEST 2002
Remotetime: Mon Aug 5 23:55:13 CEST 2002
CPU0 CPU1
0: 799080 796181 IO-APIC-edge timer
1: 7049 6986 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 42535 42656 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 102866 102704 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1963168 1976115 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2639067 2642585 IO-APIC-level eth0
24: 18 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 15189 15089 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1264459 1264395
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:53:10 CEST 2002
Remotetime: Tue Aug 6 00:01:21 CEST 2002
CPU0 CPU1
0: 817664 814472 IO-APIC-edge timer
1: 7060 7005 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 43328 43323 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 104976 104754 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1963168 1976115 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2644790 2648281 IO-APIC-level eth0
24: 18 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 15273 15178 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1294553 1294489
ERR: 2
MIS: 0
Localtime: Mon Aug 5 23:58:11 CEST 2002
Remotetime: Tue Aug 6 00:07:00 CEST 2002
CPU0 CPU1
0: 834386 831554 IO-APIC-edge timer
1: 7179 7136 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 44050 43941 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 106138 105949 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1964452 1977390 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2650015 2653482 IO-APIC-level eth0
24: 18 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 15366 15263 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1324646 1324582
ERR: 2
MIS: 0
Localtime: Tue Aug 6 00:03:12 CEST 2002
Remotetime: Tue Aug 6 00:13:06 CEST 2002
CPU0 CPU1
0: 852576 850055 IO-APIC-edge timer
1: 7288 7279 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 44750 44693 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 108250 107946 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 1965663 1978588 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2655858 2659332 IO-APIC-level eth0
24: 18 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 15462 15359 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1354741 1354677
ERR: 2
MIS: 0
Localtime: Tue Aug 6 00:08:13 CEST 2002
Remotetime: Tue Aug 6 00:19:27 CEST 2002
CPU0 CPU1
0: 871488 869187 IO-APIC-edge timer
1: 7532 7549 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 46054 46001 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 110569 110264 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 2067941 2081901 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2661907 2665401 IO-APIC-level eth0
24: 18 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 17333 17198 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1384837 1384773
ERR: 2
MIS: 0
Localtime: Tue Aug 6 00:13:14 CEST 2002
Remotetime: Tue Aug 6 00:26:21 CEST 2002
CPU0 CPU1
0: 892223 889872 IO-APIC-edge timer
1: 8208 8256 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 47433 47480 IO-APIC-edge serial
8: 8 5 IO-APIC-edge rtc
10: 113972 113615 IO-APIC-level usb-ohci
14: 18 14 IO-APIC-edge ide0
18: 2172921 2186315 IO-APIC-level EMU10K1
22: 243 244 IO-APIC-level sym53c8xx
23: 2668715 2672278 IO-APIC-level eth0
24: 18 22 IO-APIC-level ide2, ide3
26: 37713 37638 IO-APIC-level ide4
28: 3 3 IO-APIC-level sym53c8xx
29: 17465 17332 IO-APIC-level sym53c8xx
NMI: 0 0
LOC: 1414934 1414870
ERR: 2
MIS: 0
-- End --
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Heavy Clock-Drift after update from Kernel 2.4.9 to 2.4.19
2002-08-05 21:03 Heavy Clock-Drift after update from Kernel 2.4.9 to 2.4.19 Matthias Schniedermeyer
@ 2002-08-05 22:26 ` Alan Cox
2002-08-05 22:17 ` Matthias Schniedermeyer
2002-08-06 8:14 ` 2.4.19-ac4 IRQ messup? Thomas Mierau
0 siblings, 2 replies; 9+ messages in thread
From: Alan Cox @ 2002-08-05 22:26 UTC (permalink / raw)
To: Matthias Schniedermeyer; +Cc: linux-kernel
On Mon, 2002-08-05 at 22:03, Matthias Schniedermeyer wrote:
> A bit strange is that it seems to depend on load. Higher load seems to
> cause less/none clock drift.
> (e.g. when i compile something in background, the "rotating thing" in
> mozilla doesn't spin to fast)
>
> Hardware is a Dual-PIII-933Mhz. Kernel is configured as SMP.
> Any more details needed?
Can you grab /proc/interrupts every 5 minutes for an hour and send me
the resulting file ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* 2.4.19-ac4 IRQ messup?
2002-08-05 22:26 ` Alan Cox
2002-08-05 22:17 ` Matthias Schniedermeyer
@ 2002-08-06 8:14 ` Thomas Mierau
2002-08-06 8:39 ` Willy Tarreau
1 sibling, 1 reply; 9+ messages in thread
From: Thomas Mierau @ 2002-08-06 8:14 UTC (permalink / raw)
To: linux-kernel; +Cc: tmi
I encounter a kind of strange problem which seems to be related to the timer
problem. My machine is behaving differently when under load. Actually
behaving better when under load.
I am testing the eth ports and thus I am pining on both internal ports and I
am also pinging the box from another server on eth1.
Within 1 min I received 4.92062e+06 Interrupts on eth1(not bad for a 2 way
ping) and 130 Interrupts on eth0 for the 1 way ping.
The timer interrupts are 5992 which I would say pretty good for a hand reading
You can also see completly different behavior on the ports and a jamming don't
ask me where it is coming from. The box has no other task to preform.
Can anybody make any sense out of that ?
I changed the debug level for the eth driver. It returns every few seconds:
APIC error on CPU1 : 02(02) (i know not an eth message, but it pops up at
APIC error on CPU0 : 02(02) the same time)
vortex_error(), status = 0xe481
vortex_error(), status = 0xe281
vortex_error(), status = 0xe681
vortex_error(), status = 0xe081
The vortex error may be 1 to 4 messages and either one is possible in any
combination
I attach the readings
/proc/interrupts at the start
CPU0 CPU1
0: 3163847 3164837 IO-APIC-edge timer
1: 2839 2811 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
5: 2603035427 2603245593 IO-APIC-level eth1
6: 36 36 IO-APIC-edge floppy
8: 0 2 IO-APIC-edge rtc
11: 70888 69025 IO-APIC-level dpti0, eth0
12: 12580 12617 IO-APIC-edge PS/2 Mouse
14: 2 2 IO-APIC-edge ide0
NMI: 0 0
LOC: 6328682 6328831
ERR: 558
MIS: 1458
/proc/interrupts after 1 min
CPU0 CPU1
0: 3166842 3167834 IO-APIC-edge timer
1: 2898 2872 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
5: 2605498761 2605702882 IO-APIC-level eth1
6: 42 42 IO-APIC-edge floppy
8: 0 2 IO-APIC-edge rtc
11: 70951 69092 IO-APIC-level dpti0, eth0
12: 12580 12617 IO-APIC-edge PS/2 Mouse
14: 2 2 IO-APIC-edge ide0
NMI: 0 0
LOC: 6334674 6334822
ERR: 558
MIS: 1458
the ifconfig output
eth0 Link encap:Ethernet HWaddr 00:E0:81:21:FF:A2
inet addr:192.168.47.11 Bcast:192.168.47.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:125798 errors:0 dropped:0 overruns:0 frame:0
TX packets:188956 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:12327368 (11.7 Mb) TX bytes:18517194 (17.6 Mb)
Interrupt:11 Base address:0x2400
eth1 Link encap:Ethernet HWaddr 00:E0:81:21:FF:A3
inet addr:192.168.47.12 Bcast:192.168.47.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:126196 errors:0 dropped:0 overruns:0 frame:0
TX packets:63016 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:12366600 (11.7 Mb) TX bytes:6164576 (5.8 Mb)
Interrupt:5 Base address:0x2480
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:400 (400.0 b) TX bytes:400 (400.0 b)
the ping on eth0
The blocks of 5 return at the same time , as the time differnce is always 1sec
off look pretty nasty
PING 192.168.47.47 (192.168.47.47) from 192.168.47.11 eth0: 56(84) bytes of
data.
64 bytes from 192.168.47.47: icmp_seq=1 ttl=255 time=912 ms
64 bytes from 192.168.47.47: icmp_seq=2 ttl=255 time=4912 ms
64 bytes from 192.168.47.47: icmp_seq=3 ttl=255 time=3912 ms
64 bytes from 192.168.47.47: icmp_seq=4 ttl=255 time=2912 ms
64 bytes from 192.168.47.47: icmp_seq=5 ttl=255 time=1912 ms
64 bytes from 192.168.47.47: icmp_seq=6 ttl=255 time=912 ms
64 bytes from 192.168.47.47: icmp_seq=7 ttl=255 time=4905 ms
64 bytes from 192.168.47.47: icmp_seq=8 ttl=255 time=3905 ms
64 bytes from 192.168.47.47: icmp_seq=9 ttl=255 time=2905 ms
64 bytes from 192.168.47.47: icmp_seq=10 ttl=255 time=1905 ms
64 bytes from 192.168.47.47: icmp_seq=11 ttl=255 time=905 ms
64 bytes from 192.168.47.47: icmp_seq=12 ttl=255 time=4912 ms
64 bytes from 192.168.47.47: icmp_seq=13 ttl=255 time=3911 ms
64 bytes from 192.168.47.47: icmp_seq=14 ttl=255 time=2912 ms
64 bytes from 192.168.47.47: icmp_seq=15 ttl=255 time=1912 ms
64 bytes from 192.168.47.47: icmp_seq=16 ttl=255 time=912 ms
64 bytes from 192.168.47.47: icmp_seq=17 ttl=255 time=4902 ms
64 bytes from 192.168.47.47: icmp_seq=18 ttl=255 time=3902 ms
64 bytes from 192.168.47.47: icmp_seq=19 ttl=255 time=2902 ms
64 bytes from 192.168.47.47: icmp_seq=20 ttl=255 time=1902 ms
64 bytes from 192.168.47.47: icmp_seq=21 ttl=255 time=902 ms
--- 192.168.47.47 ping statistics ---
22 packets transmitted, 21 received, 4% loss, time 21039ms
rtt min/avg/max/mdev = 902.583/2812.949/4912.193/1444.073 ms, pipe 5
The ping from eth1 looks a lot better, everything again in blocks of 5 just
this time 4 good one's and 1 bad
PING 192.168.47.47 (192.168.47.47) from 192.168.47.12 eth1: 56(84) bytes of
data.
64 bytes from 192.168.47.47: icmp_seq=1 ttl=255 time=0.169 ms
64 bytes from 192.168.47.47: icmp_seq=2 ttl=255 time=0.180 ms
64 bytes from 192.168.47.47: icmp_seq=3 ttl=255 time=0.173 ms
64 bytes from 192.168.47.47: icmp_seq=4 ttl=255 time=645 ms
64 bytes from 192.168.47.47: icmp_seq=5 ttl=255 time=0.181 ms
64 bytes from 192.168.47.47: icmp_seq=6 ttl=255 time=0.174 ms
64 bytes from 192.168.47.47: icmp_seq=7 ttl=255 time=0.169 ms
64 bytes from 192.168.47.47: icmp_seq=8 ttl=255 time=0.173 ms
64 bytes from 192.168.47.47: icmp_seq=9 ttl=255 time=654 ms
64 bytes from 192.168.47.47: icmp_seq=10 ttl=255 time=0.177 ms
64 bytes from 192.168.47.47: icmp_seq=11 ttl=255 time=0.171 ms
64 bytes from 192.168.47.47: icmp_seq=12 ttl=255 time=0.173 ms
64 bytes from 192.168.47.47: icmp_seq=13 ttl=255 time=0.171 ms
64 bytes from 192.168.47.47: icmp_seq=14 ttl=255 time=653 ms
64 bytes from 192.168.47.47: icmp_seq=15 ttl=255 time=0.171 ms
64 bytes from 192.168.47.47: icmp_seq=16 ttl=255 time=0.174 ms
64 bytes from 192.168.47.47: icmp_seq=17 ttl=255 time=0.173 ms
64 bytes from 192.168.47.47: icmp_seq=18 ttl=255 time=0.170 ms
64 bytes from 192.168.47.47: icmp_seq=19 ttl=255 time=672 ms
64 bytes from 192.168.47.47: icmp_seq=20 ttl=255 time=0.181 ms
64 bytes from 192.168.47.47: icmp_seq=21 ttl=255 time=0.174 ms
64 bytes from 192.168.47.47: icmp_seq=22 ttl=255 time=0.174 ms
--- 192.168.47.47 ping statistics ---
22 packets transmitted, 22 received, 0% loss, time 21066ms
rtt min/avg/max/mdev = 0.169/119.485/672.358/253.133 ms
and last but not least a list of attached PCI devices.
The eth driver used is the 3c59x from Donald Becker
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System
Controller (rev 17).
Master Capable. Latency=64.
Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
Prefetchable 32 bit memory at 0xf6200000 [0xf6200fff].
I/O at 0x1010 [0x1013].
Bus 0, device 1, function 0:
PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge
(rev 0).
Master Capable. Latency=64. Min Gnt=4.
Bus 0, device 7, function 0:
ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 5).
Bus 0, device 7, function 1:
IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 4).
Master Capable. Latency=64.
I/O at 0x0 [0x7].
I/O at 0x0 [0x3].
I/O at 0xf000 [0xf00f].
Bus 0, device 7, function 3:
Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 3).
Master Capable. Latency=64.
Bus 0, device 9, function 0:
I2O: Distributed Processing Technology SmartRAID V Controller (rev 1).
IRQ 11.
Master Capable. Latency=64. Min Gnt=1.Max Lat=1.
Prefetchable 32 bit memory at 0xfc000000 [0xfdffffff].
Bus 0, device 9, function 1:
PCI bridge: Distributed Processing Technology PCI Bridge (rev 1).
Master Capable. Latency=64. Min Gnt=4.
Bus 0, device 16, function 0:
PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 5).
Master Capable. Latency=99. Min Gnt=12.
Bus 3, device 4, function 0:
Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART)
(rev 1).
IRQ 11.
I/O at 0x2800 [0x281f].
I/O at 0x2820 [0x282f].
I/O at 0x2848 [0x284f].
I/O at 0x2840 [0x2847].
I/O at 0x2838 [0x283f].
I/O at 0x2830 [0x2837].
Bus 3, device 7, function 0:
VGA compatible controller: ATI Technologies Inc Rage XL (rev 39).
Master Capable. Latency=66. Min Gnt=8.
Non-prefetchable 32 bit memory at 0xf5000000 [0xf5ffffff].
I/O at 0x2000 [0x20ff].
Non-prefetchable 32 bit memory at 0xf4001000 [0xf4001fff].
Bus 3, device 8, function 0:
Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T]
(rev 120).
IRQ 11.
Master Capable. Latency=80. Min Gnt=10.Max Lat=10.
I/O at 0x2400 [0x247f].
Non-prefetchable 32 bit memory at 0xf4002000 [0xf400207f].
Bus 3, device 9, function 0:
Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T]
(#2) (rev 120).
IRQ 5.
Master Capable. Latency=80. Min Gnt=10.Max Lat=10.
I/O at 0x2480 [0x24ff].
Non-prefetchable 32 bit memory at 0xf4002400 [0xf400247f].
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.4.19-ac4 IRQ messup?
2002-08-06 8:14 ` 2.4.19-ac4 IRQ messup? Thomas Mierau
@ 2002-08-06 8:39 ` Willy Tarreau
2002-08-06 9:39 ` Thomas Mierau
0 siblings, 1 reply; 9+ messages in thread
From: Willy Tarreau @ 2002-08-06 8:39 UTC (permalink / raw)
To: Thomas Mierau; +Cc: linux-kernel
On Tue, Aug 06, 2002 at 10:14:30AM +0200, Thomas Mierau wrote:
> the ping on eth0
> The blocks of 5 return at the same time , as the time differnce is always
> 1sec off look pretty nasty
I think you get intreface resets. I had such a problem with a 3c575CB (same
driver), connected to a defective chipset. I couldn't send high traffic
rates, but could receive. There is a watchdog timeout that you can reconfigure
in the 3c59x driver (I don't remember its name, use modinfo). If you reduce
the timeout, you should see reduced drifting in the pings. I used 300ms I
think. But IMHO, that's definitely not a timing problem. Perhaps in your
case, it's simply a half/full duplex misconfiguration.
Regards,
Willy
> PING 192.168.47.47 (192.168.47.47) from 192.168.47.11 eth0: 56(84) bytes of
> data.
> 64 bytes from 192.168.47.47: icmp_seq=1 ttl=255 time=912 ms
> 64 bytes from 192.168.47.47: icmp_seq=2 ttl=255 time=4912 ms
> 64 bytes from 192.168.47.47: icmp_seq=3 ttl=255 time=3912 ms
> 64 bytes from 192.168.47.47: icmp_seq=4 ttl=255 time=2912 ms
> 64 bytes from 192.168.47.47: icmp_seq=5 ttl=255 time=1912 ms
> 64 bytes from 192.168.47.47: icmp_seq=6 ttl=255 time=912 ms
> 64 bytes from 192.168.47.47: icmp_seq=7 ttl=255 time=4905 ms
> 64 bytes from 192.168.47.47: icmp_seq=8 ttl=255 time=3905 ms
> 64 bytes from 192.168.47.47: icmp_seq=9 ttl=255 time=2905 ms
> 64 bytes from 192.168.47.47: icmp_seq=10 ttl=255 time=1905 ms
> 64 bytes from 192.168.47.47: icmp_seq=11 ttl=255 time=905 ms
> 64 bytes from 192.168.47.47: icmp_seq=12 ttl=255 time=4912 ms
> 64 bytes from 192.168.47.47: icmp_seq=13 ttl=255 time=3911 ms
> 64 bytes from 192.168.47.47: icmp_seq=14 ttl=255 time=2912 ms
> 64 bytes from 192.168.47.47: icmp_seq=15 ttl=255 time=1912 ms
> 64 bytes from 192.168.47.47: icmp_seq=16 ttl=255 time=912 ms
> 64 bytes from 192.168.47.47: icmp_seq=17 ttl=255 time=4902 ms
> 64 bytes from 192.168.47.47: icmp_seq=18 ttl=255 time=3902 ms
> 64 bytes from 192.168.47.47: icmp_seq=19 ttl=255 time=2902 ms
> 64 bytes from 192.168.47.47: icmp_seq=20 ttl=255 time=1902 ms
> 64 bytes from 192.168.47.47: icmp_seq=21 ttl=255 time=902 ms
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.4.19-ac4 IRQ messup?
2002-08-06 8:39 ` Willy Tarreau
@ 2002-08-06 9:39 ` Thomas Mierau
2002-08-06 10:01 ` Willy Tarreau
0 siblings, 1 reply; 9+ messages in thread
From: Thomas Mierau @ 2002-08-06 9:39 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel
Thanks,
I looked it up its called watchdog (what else). It was set to 5000ms and I
changed it to 300ms. But the result is : no change!
I can see the transmit and receives on the switch. The problem must be the
receive part of the transceiver.
I ran mii-diag and it reports that it is set up for full duplex 100Mbit and
has a link. So that reports back ok.
Any other ideas ?
Am Dienstag, 6. August 2002 10:39 schrieb Willy Tarreau:
> On Tue, Aug 06, 2002 at 10:14:30AM +0200, Thomas Mierau wrote:
> > the ping on eth0
> > The blocks of 5 return at the same time , as the time differnce is always
> > 1sec off look pretty nasty
>
> I think you get intreface resets. I had such a problem with a 3c575CB (same
> driver), connected to a defective chipset. I couldn't send high traffic
> rates, but could receive. There is a watchdog timeout that you can
> reconfigure in the 3c59x driver (I don't remember its name, use modinfo).
> If you reduce the timeout, you should see reduced drifting in the pings. I
> used 300ms I think. But IMHO, that's definitely not a timing problem.
> Perhaps in your case, it's simply a half/full duplex misconfiguration.
>
> Regards,
> Willy
>
> > PING 192.168.47.47 (192.168.47.47) from 192.168.47.11 eth0: 56(84) bytes
> > of data.
> > 64 bytes from 192.168.47.47: icmp_seq=1 ttl=255 time=912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=2 ttl=255 time=4912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=3 ttl=255 time=3912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=4 ttl=255 time=2912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=5 ttl=255 time=1912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=6 ttl=255 time=912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=7 ttl=255 time=4905 ms
> > 64 bytes from 192.168.47.47: icmp_seq=8 ttl=255 time=3905 ms
> > 64 bytes from 192.168.47.47: icmp_seq=9 ttl=255 time=2905 ms
> > 64 bytes from 192.168.47.47: icmp_seq=10 ttl=255 time=1905 ms
> > 64 bytes from 192.168.47.47: icmp_seq=11 ttl=255 time=905 ms
> > 64 bytes from 192.168.47.47: icmp_seq=12 ttl=255 time=4912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=13 ttl=255 time=3911 ms
> > 64 bytes from 192.168.47.47: icmp_seq=14 ttl=255 time=2912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=15 ttl=255 time=1912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=16 ttl=255 time=912 ms
> > 64 bytes from 192.168.47.47: icmp_seq=17 ttl=255 time=4902 ms
> > 64 bytes from 192.168.47.47: icmp_seq=18 ttl=255 time=3902 ms
> > 64 bytes from 192.168.47.47: icmp_seq=19 ttl=255 time=2902 ms
> > 64 bytes from 192.168.47.47: icmp_seq=20 ttl=255 time=1902 ms
> > 64 bytes from 192.168.47.47: icmp_seq=21 ttl=255 time=902 ms
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.4.19-ac4 IRQ messup?
2002-08-06 9:39 ` Thomas Mierau
@ 2002-08-06 10:01 ` Willy Tarreau
2002-08-06 14:44 ` Thomas Mierau
0 siblings, 1 reply; 9+ messages in thread
From: Willy Tarreau @ 2002-08-06 10:01 UTC (permalink / raw)
To: Thomas Mierau; +Cc: Willy Tarreau, linux-kernel
On Tue, Aug 06, 2002 at 11:39:43AM +0200, Thomas Mierau wrote:
> Thanks,
> I looked it up its called watchdog (what else). It was set to 5000ms and I
> changed it to 300ms. But the result is : no change!
by "no change", you mean "still loss of 5s" ?
If this is the case, are you sure the switch port you are connected to is
in full duplex too ? does it detect receive errors or carrier lost ? I
believe that cisco switches in "spanning tree portfast" mode block the port
during 5s after a renegociation. It's easy to detect because the port's led
becomes orange.
perhaps you can switch the 2 NIC's cables to check if the problem follows the
cable or the NIC.
else I have no other clue ...
Regards,
Willy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.4.19-ac4 IRQ messup?
2002-08-06 10:01 ` Willy Tarreau
@ 2002-08-06 14:44 ` Thomas Mierau
2002-08-06 16:50 ` Henning P. Schmiedehausen
0 siblings, 1 reply; 9+ messages in thread
From: Thomas Mierau @ 2002-08-06 14:44 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Willy Tarreau, linux-kernel
I switched cables, checked the switch etc....
nothing helps.
I installed an extra PCI card which came up as eth0, making the internal ones
eth1 and eth2. No I started pinging with eth0, which was giving me strange
effects again.
eth0 = 192.168.47.11
eth1 = 192.168.47.12
eth2 = 192.168.47.13
I took a tcpdump on the receiving box. It was kind of interesting.
There were arp packages askin who is 192.168.47.11 and answers coming back
with two dofferent MAC-Id's One from the eth0 and the other one from the eth2
which was actually configured on IP .13
After I shut down etho1 and 2 and ran the box with "noapic" it preforms
perfect with the external card.
Either the NIC's are broken, or the driver or whatever. I hate that !!
> On Tue, Aug 06, 2002 at 11:39:43AM +0200, Thomas Mierau wrote:
> > Thanks,
> > I looked it up its called watchdog (what else). It was set to 5000ms and
> > I changed it to 300ms. But the result is : no change!
>
> by "no change", you mean "still loss of 5s" ?
> If this is the case, are you sure the switch port you are connected to is
> in full duplex too ? does it detect receive errors or carrier lost ? I
> believe that cisco switches in "spanning tree portfast" mode block the port
> during 5s after a renegociation. It's easy to detect because the port's led
> becomes orange.
>
> perhaps you can switch the 2 NIC's cables to check if the problem follows
> the cable or the NIC.
>
> else I have no other clue ...
>
> Regards,
> Willy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 2.4.19-ac4 IRQ messup?
2002-08-06 14:44 ` Thomas Mierau
@ 2002-08-06 16:50 ` Henning P. Schmiedehausen
0 siblings, 0 replies; 9+ messages in thread
From: Henning P. Schmiedehausen @ 2002-08-06 16:50 UTC (permalink / raw)
To: linux-kernel
Thomas Mierau <tmi@wikon.de> writes:
>I switched cables, checked the switch etc....
>nothing helps.
>I installed an extra PCI card which came up as eth0, making the internal ones
>eth1 and eth2. No I started pinging with eth0, which was giving me strange
>effects again.
>eth0 = 192.168.47.11
>eth1 = 192.168.47.12
>eth2 = 192.168.47.13
>I took a tcpdump on the receiving box. It was kind of interesting.
>There were arp packages askin who is 192.168.47.11 and answers coming back
>with two dofferent MAC-Id's One from the eth0 and the other one from the eth2
>which was actually configured on IP .13
> After I shut down etho1 and 2 and ran the box with "noapic" it preforms
>perfect with the external card.
>Either the NIC's are broken, or the driver or whatever. I hate that !!
Are they all on the same ethernet? If yes, then
a) don't do this
b) try echo "1"> /proc/sys/net/ipv4/conf/all/arp_filter
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-08-06 16:47 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-05 21:03 Heavy Clock-Drift after update from Kernel 2.4.9 to 2.4.19 Matthias Schniedermeyer
2002-08-05 22:26 ` Alan Cox
2002-08-05 22:17 ` Matthias Schniedermeyer
2002-08-06 8:14 ` 2.4.19-ac4 IRQ messup? Thomas Mierau
2002-08-06 8:39 ` Willy Tarreau
2002-08-06 9:39 ` Thomas Mierau
2002-08-06 10:01 ` Willy Tarreau
2002-08-06 14:44 ` Thomas Mierau
2002-08-06 16:50 ` Henning P. Schmiedehausen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox