Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Oct 2002 13:15:39 -0400
From:      "Andy Knapp" <knappster@knappster.net>
To:        "'Tom Snell'" <gracchus@inficad.com>, "'Hartmann, O.'" <ohartman@klima.physik.uni-mainz.de>, <freebsd-questions@FreeBSD.ORG>
Subject:   RE: microuptime() went backwards, FreeBSD 4.7-RELEASE
Message-ID:  <001601c2746e$7c776820$04291581@cobtech10>
In-Reply-To: <3DAC41EA.9040700@inficad.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I've actually had this problem before, and I am pretty sure that it is a
problem with the apm line in the generic kernel. Have you made a
customized kernel? if not, i would suggest doing that and getting rid of
all the apm lines; after that i never received these messages again.

HTH,
Andy

btw: if you do a search in the mailing list archives for "microuptime"
you can find everything you need.

-----Original Message-----
From: owner-freebsd-questions@FreeBSD.ORG
[mailto:owner-freebsd-questions@FreeBSD.ORG] On Behalf Of Tom Snell
Sent: Tuesday, October 15, 2002 12:27 PM
To: Hartmann, O.; freebsd-questions@FreeBSD.ORG
Subject: Re: microuptime() went backwards, FreeBSD 4.7-RELEASE


Hartmann, O. wrote:

>Hello.
>
>Is this subject of a bug report?
>
>While calculating numerical simulations and heavy load one of our P4 
>systems showed up this:
>microuptime() went backwards (57243.730002 -> 57243.730001)

>
>dmesgout of the system follows as attachment.
>
>
>--
>MfG
>O. Hartmann
>
>ohartman@klima.physik.uni-mainz.de
>------------------------------------------------------------------
>IT-Administration des Institutes fuer Physik der Atmosphaere (IPA)
>------------------------------------------------------------------
>Johannes Gutenberg Universitaet Mainz
>Becherweg 21
>55099 Mainz
>
>Tel: +496131/3924662 (Maschinenraum)
>Tel: +496131/3924144 (Buero)
>FAX: +496131/3923532
>  
>
>-----------------------------------------------------------------------
>-
>
>Copyright (c) 1992-2002 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 4.7-RELEASE #2: Sat Oct 12 15:12:23 CEST 2002
>    root@mail.physik.uni-mainz.de:/usr/obj/usr/src/sys/MAIL
>Timecounter "i8254"  frequency 1193182 Hz
>Timecounter "TSC"  frequency 2271871004 Hz
>CPU: Pentium 4 (2271.87-MHz 686-class CPU)
>  Origin = "GenuineIntel"  Id = 0xf24  Stepping = 4
>  
>Features=0x3febfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG
E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,<b28>,ACC>
>real memory  = 1073659904 (1048496K bytes)
>avail memory = 1041215488 (1016812K bytes)
>Preloaded elf kernel "kernel" at 0xc03ac000.
>ccd0-3: Concatenated disk drivers
>netsmb_dev: loaded
>Pentium Pro MTRR support enabled
>Using $PIR table, 9 entries at 0xc00f1be0
>npx0: <math processor> on motherboard
>npx0: INT 16 interface
>pcib0: <Host to PCI bridge> on motherboard
>pci0: <PCI bus> on pcib0
>pcib1: <PCI to PCI bridge (vendor=8086 device=2532)> at device 1.0 on
pci0
>pci1: <PCI bus> on pcib1
>pci1: <ATI model 5046 graphics accelerator> at 0.0 irq 11
>pcib2: <Intel 82801BA/BAM (ICH2) Hub to PCI bridge> at device 30.0 on
pci0
>pci2: <PCI bus> on pcib2
>pci2: <NEC uPD 9210 USB controller> at 4.0 irq 15
>pci2: <NEC uPD 9210 USB controller> at 4.1 irq 14
>pci2: <USB controller> at 4.2 irq 4
>ahc0: <Adaptec 2940A Ultra SCSI adapter> port 0xb800-0xb8ff mem
0xf5000000-0xf5000fff irq 15 at device 9.0 on pci2
>aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
>fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xb400-0xb43f mem
0xf4000000-0xf40fffff,0xf4800000-0xf4800fff irq 14 at device 10.0 on
pci2
>fxp0: Ethernet address 00:d0:b7:4c:2e:9c
>inphy0: <i82555 10/100 media interface> on miibus0
>inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>sym0: <1010-33> port 0xb000-0xb0ff mem
0xf3000000-0xf3001fff,0xf3800000-0xf38003ff irq 4 at device 11.0 on pci2
>sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking
>sym0: open drain IRQ line driver, using on-chip SRAM
>sym0: using LOAD/STORE-based firmware.
>sym0: handling phase mismatch from SCRIPTS.
>sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6 8 9 10 11 12 13
14 15.
>sym1: <1010-33> port 0xa800-0xa8ff mem
0xf2000000-0xf2001fff,0xf2800000-0xf28003ff irq 10 at device 11.1 on
pci2
>sym1: Symbios NVRAM, ID 7, Fast-80, SE, parity checking
>sym1: open drain IRQ line driver, using on-chip SRAM
>sym1: using LOAD/STORE-based firmware.
>sym1: handling phase mismatch from SCRIPTS.
>isab0: <Intel 82801BA/BAM (ICH2) PCI to LPC bridge> at device 31.0 on
pci0
>isa0: <ISA bus> on isab0
>pci0: <Unknown PCI ATA controller> at 31.1
>orm0: <Option ROMs> at iomem
0xc0000-0xcdfff,0xd0000-0xd07ff,0xd4000-0xd57ff,0xd8000-0xdbfff on isa0
>atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
>atkbd0: <AT Keyboard> irq 1 on atkbdc0
>kbd0 at atkbd0
>vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
isa0
>sc0: <System console> on isa0
>sc0: VGA <8 virtual consoles, flags=0x200>
>fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on
isa0
>fdc0: FIFO enabled, 8 bytes threshold
>fd0: <1440-KB 3.5" drive> on fdc0 drive 0
>DUMMYNET initialized (011031)
>ipfw2 initialized, divert enabled, rule-based forwarding enabled,
default to deny, logging unlimited
>IPsec: Initialized Security Association Processing.
>Waiting 3 seconds for SCSI devices to settle
>(noperiph:sym0:0:-1:-1): SCSI BUS reset delivered.
>Mounting root from ufs:/dev/da0s1a
>da0 at sym0 bus 0 target 0 lun 0
>da0: <IBM DDYS-T18350N S96H> Fixed Direct Access SCSI-3 device 
>da0: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged
Queueing Enabled
>da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
>da1 at sym0 bus 0 target 1 lun 0
>da1: <IBM IC35L018UWD210-0 S5BS> Fixed Direct Access SCSI-3 device 
>da1: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged
Queueing Enabled
>da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
>cd0 at ahc0 bus 0 target 4 lun 0
>cd0: <TEAC CD-ROM CD-532S 1.0A> Removable CD-ROM SCSI-2 device 
>cd0: 20.000MB/s transfers (20.000MHz, offset 15)
>cd0: Attempt to query device size failed: NOT READY, Medium not present
>fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6
>fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6
>link_elf: symbol splash_register undefined
>fxp0: promiscuous mode enabled
>fxp0: Microcode loaded, int_delay: 1000 usec  bundle_max: 6
>cd1 at ahc0 bus 0 target 6 lun 0
>cd1: <YAMAHA CRW3200S 1.0d> Removable CD-ROM SCSI-2 device 
>cd1: 20.000MB/s transfers (20.000MHz, offset 15)
>cd1: Attempt to query device size failed: NOT READY, Medium not present
- tray closed
>arp: runt packet
>arp: runt packet
>arp: runt packet
>arp: runt packet
>arp: runt packet
>nfs server 134.93.180.216:/usr/homes: not responding
>nfs server 134.93.180.216:/usr/homes: is alive again
>microuptime() went backwards (57243.730002 -> 57243.730001)
>arp: runt packet
>arp: runt packet
>  
>

I had a motherboard with the early AMD 751/756 (Irongate) chipset that I

was never able to install FBSD to, simply because once it booted, all it

would do was spew out megabytes of these same 'microuptime' messages. 
 The same thing happened with a number of the earlier Athlon VIA 
chipsets, too, as I recall.  It had something to do with the chipsets 
being 'flaky' (never could get a better answer), and it affects 
synchronization with the system clock somehow.

You mention this single line showed up under heavy load.  From your 
dmesg, it appears you're running all SCSI, but the line that sticks out 
for me is the "pci0: <Unknown PCI ATA controller>".....it seems you have

a brand new mobo with the latest chipset, not yet fully supported in the

kernel.  I'm not sure how this might affect you on what is basically a 
SCSI system, but it looks like it just did a single hiccup when it went 
looking for the NFS server anyway, so I don't think it's anything to 
worry about.  Unless this box is used for heavy number-crunching (which 
it probably is, being in the Physics department), it's nothing to worry 
about, but I'd periodically grep /var/log/messages for the 'microuptime'

to see if and when it appears again, and perhaps compare results of 
several number-crunching exercises run on this box and another 
"known-good" box to ensure integrity.  Hope this helps a little....

Tom Snell



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001601c2746e$7c776820$04291581>