microuptime() went backwards... on a K7 with 7kxa mobo
Thought I would use my old K7 600 MHz and 7KXA mobo as a gateway since my old K6-2 died, and have run into a common problem when I installed 4.9. When under high IO (network or CPU use) I get the "microuptime() went backwards" flooding my screen, and syslog logging it making the system crawl until syslog is killed. I have went through the standard procedure, disabled APM in bios and removing it from the kernel, made sure sysctl kern.timecounter.method is set to 1, but to no help. Anyone got any hints? -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: microuptime() went backwards
On Fri, 23 Apr 2004 13:41:18 +0100, Matthew Seaman <[EMAIL PROTECTED]> wrote: On Fri, Apr 23, 2004 at 01:13:11PM +0100, Jez Hancock wrote: On Fri, Apr 23, 2004 at 09:04:56AM +0300, hugle wrote: > SOmetimes I see such messages in dmesg. > > perl# dmesg > uptime() went backwards (1574174.333073 -> 1573478.944788) > > what they mean? and what causes them to appear ? > is it good or bad?? :) I'd always presumed these messages occured on my machine because the ntpd (network time protocol daemon) had adjusted the system clock. I can't actually tell you for sure since the messages aren't logged by syslog here so there's no easy way of comparing the times to see if they correspond to the ntpd adjustments. ntpd can be configured to maintain a log file and does, if I recall correctly, log a warning messages each time it is forced to step rather than slew the time (see below). Check to see if you have ntpd running - if so that's probably the reason for the messages. Actually, that shouldn't happen because of ntpd(8). If ntpd detects that your system clock is fast, it will make it run slightly slower until it gradually comes back into synch. It shouldn't ever jump the system clock to the right time during normal operation, neither should it ever cause the system clock to run backwards. A partial excerpt from man ntpd(8): -x Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option forces the time to be slewed in all cases. If the step threshold is set to zero, all offsets are stepped, regardless of value and regardless of the -x option. In general, this is not a good idea, as it bypasses the clock state machine which is designed to cope with large time and frequency errors Note: Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize. This option can be used with the -q option. How NTP Operates ... As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. -Danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: microuptime() went backwards
At 01:04 AM 4/23/2004, you wrote: Hello all. SOmetimes I see such messages in dmesg. perl# dmesg uptime() went backwards (1574174.333073 -> 1573478.944788) what they mean? and what causes them to appear ? is it good or bad?? :) -- Best regards,Hugle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" Simply comment out (Disable) the device apm in your kernel and recompile. That's what fixed it for me. Peter --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: microuptime() went backwards
On Fri, Apr 23, 2004 at 01:13:11PM +0100, Jez Hancock wrote: > On Fri, Apr 23, 2004 at 09:04:56AM +0300, hugle wrote: > > > SOmetimes I see such messages in dmesg. > > > > perl# dmesg > > uptime() went backwards (1574174.333073 -> 1573478.944788) > > > > what they mean? and what causes them to appear ? > > is it good or bad?? :) > > I'd always presumed these messages occured on my machine because the > ntpd (network time protocol daemon) had adjusted the system clock. I > can't actually tell you for sure since the messages aren't logged by > syslog here so there's no easy way of comparing the times to see if they > correspond to the ntpd adjustments. > > Check to see if you have ntpd running - if so that's probably the reason > for the messages. Actually, that shouldn't happen because of ntpd(8). If ntpd detects that your system clock is fast, it will make it run slightly slower until it gradually comes back into synch. It shouldn't ever jump the system clock to the right time during normal operation, neither should it ever cause the system clock to run backwards. Of course, there is an exception: right after boot, it's usual to run ntpdate(8), and fairly common to run that with the '-b' flag so that the time gets stepped straight to the correct value. The ntpd developers have marked ntpdate for eventual retirement and have rolled its functionality into the main ntpd(8) -- so 'ntpq -q' is meant to be functionally equivalent to ntpdate. Even so, it's not clear to me that the 'step the clock' mode of operation is available from 'ntpd -q'. The OP's original query about 'microuptime went backwards' is something that has come up fairly frequently on various mailing lists. Googling for that message returns a few hundred hits. There has been quite a lot of effort to eradicate it, but apparently not with complete success yet. Most of the time it was apparently due to problems with apm on certain hardware, but it could be caused by other factors. With the switch to APCI in 5.x there have been far fewer reports of these errors appearing. Usually this is pretty innocuous. If you're only getting these messages occasionally, then you can probably just ignore them. On the other hand, if you've suddenly started to get floods of these messages for no apparent reason, it may possibly indicate that you have hardware which is starting to get a bit marginal. Keep the system under observation, backup religiously and check the log messages for clues regularly. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: microuptime() went backwards
On Fri, Apr 23, 2004 at 09:04:56AM +0300, hugle wrote: > SOmetimes I see such messages in dmesg. > > perl# dmesg > uptime() went backwards (1574174.333073 -> 1573478.944788) > > what they mean? and what causes them to appear ? > is it good or bad?? :) I'd always presumed these messages occured on my machine because the ntpd (network time protocol daemon) had adjusted the system clock. I can't actually tell you for sure since the messages aren't logged by syslog here so there's no easy way of comparing the times to see if they correspond to the ntpd adjustments. Check to see if you have ntpd running - if so that's probably the reason for the messages. -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ http://jez.hancock-family.com/ - Another FreeBSD Diary http://ipfwstats.sf.net/- ipfw peruser traffic logging ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: microuptime() went backwards
On Fri, 2004-04-23 at 11:34, hugle wrote: > Hello all. > SOmetimes I see such messages in dmesg. > > perl# dmesg > uptime() went backwards (1574174.333073 -> 1573478.944788) > Is your system clock working fine ? > what they mean? and what causes them to appear ? > is it good or bad?? :) --- Vijay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
microuptime() went backwards
Hello all. SOmetimes I see such messages in dmesg. perl# dmesg uptime() went backwards (1574174.333073 -> 1573478.944788) what they mean? and what causes them to appear ? is it good or bad?? :) -- Best regards,Hugle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: microuptime() went backwards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Quoting talon <[EMAIL PROTECTED]>: | re microuptime. | | My guess is that you will get 10^7 replies to this chestnut! :-) Ok Thanks Heaps .. Il definately do that! Thanks Again Jason FreeBSD Rox My Sox :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: Signed By Talon With GnuPG iD8DBQE+K3XEyoJQBYFw6XARAjJXAJ9wmi1hCelI5rCNUuQjCMTwOZ6wdwCdEJwU LHTmCBuRUdQr6g66u2Rpwjs= =BZ+I -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: microuptime() went backwards
Quoting talon <[EMAIL PROTECTED]>: re microuptime. My guess is that you will get 10^7 replies to this chestnut! :-) 1. Reconfigure your kernel by deleting all reference to APM, Leaving it in the default disabled state will not be enough. 2. Remove APM from your BIOS settings. IIRC that's about it. -- Brian --- This message sent through Adam Internet Webmail http://www.adam.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
microuptime() went backwards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All ... I have a slight problem with a box that i am looking after. Any tips would be appreciated. logfile /var/log/messages -- very tiny sample Jan 20 14:06:22 gateway /kernel: microuptime() went backwards (164603.803615 -> 163908.386002) Jan 20 14:06:23 gateway /kernel: microuptime() went backwards (164604.294457 -> 164604.254897) Jan 20 14:06:23 gateway /kernel: microuptime() went backwards (164604.326398 -> 163908.912778) Jan 20 14:06:24 gateway /kernel: microuptime() went backwards (164604.765647 -> 164604.750630) Jan 20 14:06:24 gateway /kernel: microuptime() went backwards (164604.765647 -> 164604.751335) Jan 20 14:06:25 gateway /kernel: microuptime() went backwards (164604.765647 -> 163909.399092) Jan 20 14:06:25 gateway /kernel: microuptime() went backwards (164605.196560 -> 164605.192186) Jan 20 14:06:27 gateway /kernel: microuptime() went backwards (164605.196560 -> 163909.835651) Jan 20 14:06:28 gateway /kernel: microuptime() went backwards (164605.648055 -> 164605.646256) - -- I was told this problem was due to a faulty cmos clock :( (Not By This List) After changing the mob the problem still occurs ... I have had a look about in the archives but havnt been able to find anything that might suggest a fix. The box is a dual homed system connected to an adsl router and small 20 machine lan acting as packetfilter and ipnat gateway. Realtech nics 512mb ram Asus Mainboard and AMD duron 900 cpu The OS is FreeBSD 4.7-STABLE If any one has been here before .. thanks in advance for any tip on fixing the prob ... Best Regards Jason -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: Signed By Talon With GnuPG iD8DBQE+K29ryoJQBYFw6XARAu8OAKCPwdvdlpnuKUXM5+8WA1iX614suQCglgmd xRqDMyzOLBfoko5snhE5r3Q= =LYNz -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: microuptime went backwards ??
Quoting Christopher Rosado <[EMAIL PROTECTED]>: > > On Wed, 4 Dec 2002 14:41:50 +1030 > [EMAIL PROTECTED] wrote: > > BCA> Makes no difference. As Greg Lehey explained earlier the only > BCA> solution is to delete all reference to APM in your kernel config file. > > He did? I see no such message from him in this thread. > > BCA> "Disabled" means "still there but not being used". > > Funnily enough, commenting it out in the kernel config certainly removes APM > support from the kernel... thus _disabling_ that particular feature. > > BCA> What we want is NOT PRESENT in any shape or form. > > Again, merely commenting it out of the config is sufficient, though > completely removing it from the config serves the same purpose. OK - do it your way. It won't work, but YOU will be right. Well done. Regards, Brian --- This message sent through Adam Internet Webmail http://www.adam.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: microuptime went backwards ??
On Wed, 4 Dec 2002 14:41:50 +1030 [EMAIL PROTECTED] wrote: BCA> Makes no difference. As Greg Lehey explained earlier the only BCA> solution is to delete all reference to APM in your kernel config file. He did? I see no such message from him in this thread. BCA> "Disabled" means "still there but not being used". Funnily enough, commenting it out in the kernel config certainly removes APM support from the kernel... thus _disabling_ that particular feature. BCA> What we want is NOT PRESENT in any shape or form. Again, merely commenting it out of the config is sufficient, though completely removing it from the config serves the same purpose. There is no functional difference between commenting-out a feature and removing the entry aside from leaving a reminder that the feature in question was disabled; which is a good idea to do, since someone may forget that he'd disabled/removed a feature for a reason if there's no visual reminder in the config. I won't argue semantics any further though since that's just silly. All I know is that when I switched to FreeBSD last year, I ran into this problem (and lost a hard drive due to the innumerable spontaneous reboots in the process), and the only way to fix it was to disable APM in the BIOS and kernel. -- Christopher Rosado To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: microuptime went backwards ??
Quoting Bertrand Habib <[EMAIL PROTECTED]>: > > >BH> "microuptime() went backwards ( nnn.nn -> mmm.m )" > > > >Sounds like an AMD Athlon. > > Yes > > >Disable power management in your BIOS. > > Nop! It was disabled and this brough me to the microuptime problem. > After having re-enabled it (i.e: ACPI enable, APM enable), it seams to work. > > >Also, I recommend disabling it in > >the kernel as well. NOT ENOUGH! > Kernel is GENERIC (in fact I did'nt checked if APM was still disabled in > 4.7 GENRIC ). Makes no difference. As Greg Lehey explained earlier the only solution is to delete all reference to APM in your kernel config file. "Disabled" means "still there but not being used". What we want is NOT PRESENT in any shape or form. Regards, Brian --- This message sent through Adam Internet Webmail http://www.adam.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: microuptime went backwards ??
BH> "microuptime() went backwards ( nnn.nn -> mmm.m )" Sounds like an AMD Athlon. Yes Disable power management in your BIOS. Nop! It was disabled and this brough me to the microuptime problem. After having re-enabled it (i.e: ACPI enable, APM enable), it seams to work. Also, I recommend disabling it in the kernel as well. Kernel is GENERIC (in fact I did'nt checked if APM was still disabled in 4.7 GENRIC ). # Power management support (see LINT for more options) # deviceapm0at nexus? disable flags 0x20 # Advanced Power Management # Disable due to microuptime() issue last year New kernel build ongoing accordingly your config tip. Last word: many thanks for your help, Christopher :) Bertrand To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: microuptime went backwards ??
On Tue, 03 Dec 2002 16:49:48 -0800 Bertrand Habib <[EMAIL PROTECTED]> wrote: BH> Dear all, BH> BH> writing on ata disk, i get full screens of BH> "microuptime() went backwards ( nnn.nn -> mmm.m )" Sounds like an AMD Athlon. BH> with mmm.m being less than nnn.n (i.e backwards ) BH> Broken hardware ? BH> Wo may help me to interpret this message and, eventualy, correct that BH> issue ? Disable power management in your BIOS. Also, I recommend disabling it in the kernel as well. I had this exact same problem last year, and had to do that. I don't recall if it absolutely had to be disabled in the kernel or if I did that just to be on the safe side, but do it just to be on the safe side :) Comment out "Device apm0" in your kernel config (here's the relevant bit from my config) # Power management support (see LINT for more options) # deviceapm0at nexus? disable flags 0x20 # Advanced Power Management # Disable due to microuptime() issue last year -- Christopher Rosado To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
microuptime went backwards ??
Dear all, writing on ata disk, i get full screens of "microuptime() went backwards ( nnn.nn -> mmm.m )" with mmm.m being less than nnn.n (i.e backwards ) Broken hardware ? Wo may help me to interpret this message and, eventualy, correct that issue ? Many thanks in advance for your tips. Kindest regards Bertrand Details: --- Athlon 800 cpu on 771AS motherboard 40GB Maxtor 6L040J2 FreeBSD 4.7-RELEASE with GENERIC kernel (can't compile a new one) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: microuptime() went backwards, FreeBSD 4.7-RELEASE
On Wednesday 16 October 2002 04:20, Hartmann, O. wrote: > On Tue, 15 Oct 2002, Andy Knapp wrote: > > No, on our servers I disabled APM by default because it triggered trouble > in the past on several SMP machines. And why APM on every-time-up servers? > No, definitely no APM facilities in kernel or BIOS enabled! > > :>are there any references to apm in it? seems the default reference, > :>which says to disable it, doesn't work correctly... This is getting to be a FAQ. Disabled isn't the same as not present. APM must be not present in the kernel if microuptime backwards is to be avoided. ie recompile with the apm lines REMOVED ALTOGETHER in your config. I thought this problem was confined to Athlon CPUs on VIA chipset mobos - apparently not so. -- Regards, Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
RE: microuptime() went backwards, FreeBSD 4.7-RELEASE
On Tue, 15 Oct 2002, Andy Knapp wrote: No, on our servers I disabled APM by default because it triggered trouble in the past on several SMP machines. And why APM on every-time-up servers? No, definitely no APM facilities in kernel or BIOS enabled! :>are there any references to apm in it? seems the default reference, :>which says to disable it, doesn't work correctly... :> :>-andy :> :>-Original Message- :>From: [EMAIL PROTECTED] :>[mailto:[EMAIL PROTECTED]] On Behalf Of Hartmann, O. :>Sent: Tuesday, October 15, 2002 1:32 PM :>To: Andy Knapp :>Cc: 'Tom Snell'; [EMAIL PROTECTED] :>Subject: RE: microuptime() went backwards, FreeBSD 4.7-RELEASE :> :> :>On Tue, 15 Oct 2002, Andy Knapp wrote: :> :>This machine has a highly customized kernel ... :> :>:>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: [EMAIL PROTECTED] :>:>[mailto:[EMAIL PROTECTED]] On Behalf Of Tom Snell :>:>Sent: Tuesday, October 15, 2002 12:27 PM :>:>To: Hartmann, O.; [EMAIL PROTECTED] :>:>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 :>:>> :>:>>[EMAIL PROTECTED] :>:>>-- :>:>>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 :>:>>[EMAIL PROTECTED]:/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=0x3febfbffPG :>:>E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,,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: on motherboard :>:>>npx0: INT 16 interface :>:>>pcib0: on motherboard :>:>>pci0: on pcib0 :>:>>pcib1: at device 1.0 on :>:>pci0 :>:>>pci1: on pcib1 :>:>>pci1: at 0.0 irq 11 :>:>>pcib2: at device 30.0 on :>:>pci0 :>:>>pci2: on pcib2 :>:>>pci2: at 4.0 irq 15 :>:>>pci2: at 4.1 irq 14 :>:>>pci2: at 4.2 irq 4 :>:>>ahc0: port 0xb800-0xb8ff mem :>:>0xf500-0xf5000fff irq 15 at device 9.0 on pci2 :>:>>aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs :>:>>fxp0: port 0xb400-0xb43f mem :>:>0xf400-0xf40f,0xf480-0xf4800fff irq 14 at device 10.0 on :>:>pci2 :>:>>fxp0: Ethernet address 00:d0:b7:4c:2e:9c :>:>>inphy0: on miibus0 :>:>>inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto :>:>>sym0: <1010-33> port 0xb000-0xb0ff mem :>:>0xf300-0xf3001fff,0xf380-0xf38003ff irq 4 at dev
RE: microuptime() went backwards, FreeBSD 4.7-RELEASE
are there any references to apm in it? seems the default reference, which says to disable it, doesn't work correctly... -andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Hartmann, O. Sent: Tuesday, October 15, 2002 1:32 PM To: Andy Knapp Cc: 'Tom Snell'; [EMAIL PROTECTED] Subject: RE: microuptime() went backwards, FreeBSD 4.7-RELEASE On Tue, 15 Oct 2002, Andy Knapp wrote: This machine has a highly customized kernel ... :>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: [EMAIL PROTECTED] :>[mailto:[EMAIL PROTECTED]] On Behalf Of Tom Snell :>Sent: Tuesday, October 15, 2002 12:27 PM :>To: Hartmann, O.; [EMAIL PROTECTED] :>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 :>> :>>[EMAIL PROTECTED] :>>-- :>>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 :>>[EMAIL PROTECTED]:/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=0x3febfbffE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,,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: on motherboard :>>npx0: INT 16 interface :>>pcib0: on motherboard :>>pci0: on pcib0 :>>pcib1: at device 1.0 on :>pci0 :>>pci1: on pcib1 :>>pci1: at 0.0 irq 11 :>>pcib2: at device 30.0 on :>pci0 :>>pci2: on pcib2 :>>pci2: at 4.0 irq 15 :>>pci2: at 4.1 irq 14 :>>pci2: at 4.2 irq 4 :>>ahc0: port 0xb800-0xb8ff mem :>0xf500-0xf5000fff irq 15 at device 9.0 on pci2 :>>aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs :>>fxp0: port 0xb400-0xb43f mem :>0xf400-0xf40f,0xf480-0xf4800fff irq 14 at device 10.0 on :>pci2 :>>fxp0: Ethernet address 00:d0:b7:4c:2e:9c :>>inphy0: on miibus0 :>>inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto :>>sym0: <1010-33> port 0xb000-0xb0ff mem :>0xf300-0xf3001fff,0xf380-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 :>0xf200-0xf2001fff,0xf280-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: at device 31.0 on :>pci0 :>>isa0
RE: microuptime() went backwards, FreeBSD 4.7-RELEASE
On Tue, 15 Oct 2002, Andy Knapp wrote: This machine has a highly customized kernel ... :>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: [EMAIL PROTECTED] :>[mailto:[EMAIL PROTECTED]] On Behalf Of Tom Snell :>Sent: Tuesday, October 15, 2002 12:27 PM :>To: Hartmann, O.; [EMAIL PROTECTED] :>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 :>> :>>[EMAIL PROTECTED] :>>-- :>>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 :>>[EMAIL PROTECTED]:/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=0x3febfbffE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,,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: on motherboard :>>npx0: INT 16 interface :>>pcib0: on motherboard :>>pci0: on pcib0 :>>pcib1: at device 1.0 on :>pci0 :>>pci1: on pcib1 :>>pci1: at 0.0 irq 11 :>>pcib2: at device 30.0 on :>pci0 :>>pci2: on pcib2 :>>pci2: at 4.0 irq 15 :>>pci2: at 4.1 irq 14 :>>pci2: at 4.2 irq 4 :>>ahc0: port 0xb800-0xb8ff mem :>0xf500-0xf5000fff irq 15 at device 9.0 on pci2 :>>aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs :>>fxp0: port 0xb400-0xb43f mem :>0xf400-0xf40f,0xf480-0xf4800fff irq 14 at device 10.0 on :>pci2 :>>fxp0: Ethernet address 00:d0:b7:4c:2e:9c :>>inphy0: on miibus0 :>>inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto :>>sym0: <1010-33> port 0xb000-0xb0ff mem :>0xf300-0xf3001fff,0xf380-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 :>0xf200-0xf2001fff,0xf280-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: at device 31.0 on :>pci0 :>>isa0: on isab0 :>>pci0: at 31.1 :>>orm0: at iomem :>0xc-0xcdfff,0xd-0xd07ff,0xd4000-0xd57ff,0xd8000-0xdbfff on isa0 :>>atkbdc0: at port 0x60,0x64 on isa0 :>>atkbd0: irq 1 on atkbdc0 :>>kbd0 at atkbd0 :>>vga0: at port 0x3c0-0x3df iomem 0xa-0xb on :>isa0 :>>sc0: on isa0 :>>sc0: VGA <8 virtual consoles, flags=0x200> :>>fd
RE: microuptime() went backwards, FreeBSD 4.7-RELEASE
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Snell Sent: Tuesday, October 15, 2002 12:27 PM To: Hartmann, O.; [EMAIL PROTECTED] 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 > >[EMAIL PROTECTED] >-- >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 >[EMAIL PROTECTED]:/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,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: on motherboard >npx0: INT 16 interface >pcib0: on motherboard >pci0: on pcib0 >pcib1: at device 1.0 on pci0 >pci1: on pcib1 >pci1: at 0.0 irq 11 >pcib2: at device 30.0 on pci0 >pci2: on pcib2 >pci2: at 4.0 irq 15 >pci2: at 4.1 irq 14 >pci2: at 4.2 irq 4 >ahc0: port 0xb800-0xb8ff mem 0xf500-0xf5000fff irq 15 at device 9.0 on pci2 >aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs >fxp0: port 0xb400-0xb43f mem 0xf400-0xf40f,0xf480-0xf4800fff irq 14 at device 10.0 on pci2 >fxp0: Ethernet address 00:d0:b7:4c:2e:9c >inphy0: on miibus0 >inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >sym0: <1010-33> port 0xb000-0xb0ff mem 0xf300-0xf3001fff,0xf380-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 0xf200-0xf2001fff,0xf280-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: at device 31.0 on pci0 >isa0: on isab0 >pci0: at 31.1 >orm0: at iomem 0xc-0xcdfff,0xd-0xd07ff,0xd4000-0xd57ff,0xd8000-0xdbfff on isa0 >atkbdc0: at port 0x60,0x64 on isa0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 >sc0: on isa0 >sc0: VGA <8 virtual consoles, flags=0x200> >fdc0: 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: 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:
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 > >[EMAIL PROTECTED] >-- >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 >[EMAIL PROTECTED]:/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,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: on motherboard >npx0: INT 16 interface >pcib0: on motherboard >pci0: on pcib0 >pcib1: at device 1.0 on pci0 >pci1: on pcib1 >pci1: at 0.0 irq 11 >pcib2: at device 30.0 on pci0 >pci2: on pcib2 >pci2: at 4.0 irq 15 >pci2: at 4.1 irq 14 >pci2: at 4.2 irq 4 >ahc0: port 0xb800-0xb8ff mem 0xf500-0xf5000fff >irq 15 at device 9.0 on pci2 >aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs >fxp0: port 0xb400-0xb43f mem >0xf400-0xf40f,0xf480-0xf4800fff irq 14 at device 10.0 on pci2 >fxp0: Ethernet address 00:d0:b7:4c:2e:9c >inphy0: on miibus0 >inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >sym0: <1010-33> port 0xb000-0xb0ff mem 0xf300-0xf3001fff,0xf380-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 0xf200-0xf2001fff,0xf280-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: at device 31.0 on pci0 >isa0: on isab0 >pci0: at 31.1 >orm0: at iomem >0xc-0xcdfff,0xd-0xd07ff,0xd4000-0xd57ff,0xd8000-0xdbfff on isa0 >atkbdc0: at port 0x60,0x64 on isa0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 >sc0: on isa0 >sc0: VGA <8 virtual consoles, flags=0x200> >fdc0: 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: 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: 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: 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_d
microuptime() went backwards, FreeBSD 4.7-RELEASE
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 [EMAIL PROTECTED] -- 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 [EMAIL PROTECTED]:/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,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: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 pcib2: at device 30.0 on pci0 pci2: on pcib2 pci2: at 4.0 irq 15 pci2: at 4.1 irq 14 pci2: at 4.2 irq 4 ahc0: port 0xb800-0xb8ff mem 0xf500-0xf5000fff irq 15 at device 9.0 on pci2 aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs fxp0: port 0xb400-0xb43f mem 0xf400-0xf40f,0xf480-0xf4800fff irq 14 at device 10.0 on pci2 fxp0: Ethernet address 00:d0:b7:4c:2e:9c inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: <1010-33> port 0xb000-0xb0ff mem 0xf300-0xf3001fff,0xf380-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 0xf200-0xf2001fff,0xf280-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: at device 31.0 on pci0 isa0: on isab0 pci0: at 31.1 orm0: at iomem 0xc-0xcdfff,0xd-0xd07ff,0xd4000-0xd57ff,0xd8000-0xdbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <8 virtual consoles, flags=0x200> fdc0: 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: 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: 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: 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: 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
