Bug 160691 - Negative ping times (serious time keeping problem?) on PII-Celeron system
Summary: Negative ping times (serious time keeping problem?) on PII-Celeron system
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-13 01:10 UTC by freebsd-prs
Modified: 2017-12-31 22:32 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description freebsd-prs 2011-09-13 01:10:09 UTC
Just put FreeBSD 8.1 up on an old (but good) 500 MHz Celeron with half a gig of RAM. Interfaces are classic xl (3Com) and dc (DEC tulip). Works quite nicely except for one quirk: ping times that ought to be positive (no more than 200 ms worst case) are coming out negative! System stability is also a bit dicey; have seen several complete system hangs with no messages indicating the cause. 
dmesg output is as follows:

Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.1-RELEASE-p2 #5: Fri Apr 15 16:10:53 MST 2011
    brett@washington.lariat.net:/usr/obj/usr/src/sys/WASHINGTON i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x665  Family = 6  Model = 6  Stepping = 5
  Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
real memory  = 536870912 (512 MB)
avail memory = 515813376 (491 MB)
acpi0: <AMIINT AMIINT10> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
cpu0: <ACPI CPU> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
atapci0: <SiS 620 UDMA66 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at devic
e 0.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
isab0: <PCI-ISA bridge> at device 1.0 on pci0
isa0: <ISA bus> on isab0
pci0: <unknown> at device 1.1 (no driver attached)
pci0: <serial bus, USB> at device 1.2 (no driver attached)
pcib1: <PCI-PCI bridge> at device 2.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xbc00-0xbc7f mem 0xee800000-0xeeffffff,0xef6f0000-0xef6fffff
 irq 11 at device 0.0 on pci1
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdc00-0xdc7f mem 0xefffaf80-0xefffafff irq 11 at devic
e 8.0 on pci0
miibus0: <MII bus> on xl0
xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:01:03:be:8b:c1
xl0: [ITHREAD]
dc0: <ADMtek AN985 10/100BaseTX> port 0xd800-0xd8ff mem 0xefffa800-0xefffabff irq 12 at device 9.0 o
n pci0
miibus1: <MII bus> on dc0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: Ethernet address: 00:14:bf:5b:f5:ed
dc0: [ITHREAD]
xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xefffaf00-0xefffaf7f irq 9 at device
 10.0 on pci0
miibus2: <MII bus> on xl1
xlphy1: <3Com internal media interface> PHY 24 on miibus2
xlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl1: Ethernet address: 00:40:ca:97:13:7a
xl1: [ITHREAD]
acpi_button0: <Power Button> on acpi0
acpi_button0: enable wake failed
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xd7fff pnpid ORM0000 on is
a0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
Timecounter "TSC" frequency 501141912 Hz quality 800
Timecounters tick every 1.000 msec
ipfw2 initialized, divert loadable, nat enabled, rule-based forwarding enabled, default to accept, l
ogging disabled
load_dn_sched dn_sched PRIO loaded
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched WF2Q+ loaded
load_dn_sched dn_sched FIFO loaded
ad0: 9787MB <QUANTUM FIREBALLlct10 10 A03.0900> at ata0-master UDMA66

Pings, even to localhost, sometimes show show negative times:

# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=-0.148 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=-0.151 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=-686.111 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=-0.180 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.110 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=686.351 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=-686.376 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.121 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=-686.402 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=-686.105 ms
64 bytes from 127.0.0.1: icmp_seq=10 ttl=64 time=686.623 ms
64 bytes from 127.0.0.1: icmp_seq=11 ttl=64 time=0.107 ms
64 bytes from 127.0.0.1: icmp_seq=12 ttl=64 time=0.119 ms
64 bytes from 127.0.0.1: icmp_seq=13 ttl=64 time=0.418 ms
64 bytes from 127.0.0.1: icmp_seq=14 ttl=64 time=0.401 ms
64 bytes from 127.0.0.1: icmp_seq=15 ttl=64 time=-0.169 ms
64 bytes from 127.0.0.1: icmp_seq=16 ttl=64 time=0.113 ms
64 bytes from 127.0.0.1: icmp_seq=17 ttl=64 time=0.401 ms
64 bytes from 127.0.0.1: icmp_seq=18 ttl=64 time=-686.117 ms
64 bytes from 127.0.0.1: icmp_seq=19 ttl=64 time=0.115 ms
64 bytes from 127.0.0.1: icmp_seq=20 ttl=64 time=0.111 ms

Clearly something is odd about timekeeping in this system (SiS motherboard chipset, PII-generation Celeron but still effectively a "686") which was not a problem when it was running FreeBSD 4.11-RELEASE (as it was before). Possible causes: Kernel now thinks all CPUs must be faster than this older chip; race condition in kernel; problems handling system timer.

Fix: 

None known. Experimenting with different kernel options and with varying kern.hz.
How-To-Repeat: Install FreeBSD 8.1-RELEASE on this motherboard (SiS chipset) and ping localhost.
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:37 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped