PM 2/17/2002 +1100, Bruce Evans wrote:
On Sat, 16 Feb 2002, Matthew Dillon wrote:
Testing with a 'make -j 10 buildworld' on a -current box I am getting
regular:
microuptime() went backwards (146.826785 - 146.156715)
microuptime() went backwards (146.826782 - 146.228636
:I just wrote the following fix for some of the overflow problems.
I don't understand how this code is supposed to handle overflows.
You seem only to be checking to see if the master timecounter has
changed to a different type.
-Matt
In message [EMAIL PROTECTED], Bruce Evans writes:
This occurs both with and without the gettimeofday Giant-removal patch, so
I am fairly sure it has nothing to do with any of my current work. This is
running -current on a DELL2550 (2xCPUs), compiled with the SMP option.
The Gian removal
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
:I just wrote the following fix for some of the overflow problems.
I don't understand how this code is supposed to handle overflows.
You seem only to be checking to see if the master timecounter has
changed to a different type.
Ok, I've looked at the code more carefully and I understand how this
works now. However, it is not enough in an SMP environment. You
need a generation count in the timecounter structure and you also need
a synchronization point when you switch time counters or a process
:Bruce's patch amounts to a retry if the current timecounter was updated
:while we were calculating time. It is a bit more defensive than it
:needs to be and generally pessimizes the timecounters elegant lockless
:design a fair bit, but it is still much better than slamming a mutex
:around the
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went backwards (775.159625 - 775.159612)
I also think
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
However, I think to be complete we need to make it even less elegant.
The TC module is only flip-flopping between two time counters, which
means that it can flip-flop twice and the test will not work. We need
a generation
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went
Matt,
Easy now, there is more depth to it than that... I have promised myself
to get the timecounter paper written and I'll probably present it at
BSDcon-euro-2002 in Amsterdam if they want to listen to me.
For now, lets concentrate on the PIIX hardware because that's where
the problem seems
If this patch cures the PIIX problem, something I'm not at all convinced
about, it should go in, if not only the comment should go in.
I would like to see the PIIX problem caught on camera, personally.
We're aware of one errata for it already, and we work around it. If
there's another
:I would like to see the PIIX problem caught on camera, personally.
:We're aware of one errata for it already, and we work around it. If
:there's another problem, or ideally if someone has some relatively quick
:code to test it, that would be much better.
Holy shit. We are
Ok, here is a patch that executes a brute-force solution to the
asynchronous counter problem.
Basically it figures out a mask and then the timer code loops until two
masked reads yield the same value, guarenteeing that we haven't caught
the timer during a carry.
On my
:Sounds like we need to smack whoever made your chipset as well. Intel
:learned their lesson (finally) with later revisions of the PIIX4. I'm
:guessing you're running this against a ServerWorks system.
atapci0: ServerWorks ROSB4 ATA33 controller port 0x8b0-0x8bf at device 15.1 on
pci0
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
:I would like to see the PIIX problem caught on camera, personally.
:We're aware of one errata for it already, and we work around it. If
:there's another problem, or ideally if someone has some relatively quick
:code to test it, that
Ok, here is a patch that executes a brute-force solution to the
asynchronous counter problem.
Basically it figures out a mask and then the timer code loops until two
masked reads yield the same value, guarenteeing that we haven't caught
the timer during a carry.
:I would like to see the PIIX problem caught on camera, personally.
:We're aware of one errata for it already, and we work around it. If
:there's another problem, or ideally if someone has some relatively quick
:code to test it, that would be much better.
Holy shit. We are
:
:I have some reservations about this, because I'm not sure that 10
:successive reads will catch the ripple-counter problem that the old PIIX4s
:have.
Just goes to show that I need to document my code :-)
Those reads are not detecting the ripple-counter problem, they are
figuring
On Sun, 17 Feb 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bruce Evans writes:
This occurs both with and without the gettimeofday Giant-removal patch, so
I am fairly sure it has nothing to do with any of my current work. This is
running -current on a DELL2550 (2xCPUs),
On Sun, 17 Feb 2002, Matthew Dillon wrote:
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went
Testing with a 'make -j 10 buildworld' on a -current box I am getting
regular:
microuptime() went backwards (146.826785 - 146.156715)
microuptime() went backwards (146.826782 - 146.228636)
...
microuptime() went backwards (8945.938288 - 8945.251603)
microuptime() went
On Sat, 16 Feb 2002, Matthew Dillon wrote:
Testing with a 'make -j 10 buildworld' on a -current box I am getting
regular:
microuptime() went backwards (146.826785 - 146.156715)
microuptime() went backwards (146.826782 - 146.228636)
...
microuptime() went backwards
messages about microuptime went
backwards which doesn't seem to hurt the system itself but is very
annoying to work with as it jams the whole screen in a matter of
seconds with error messages, thus making it impossible to really work
with the system. Now in some mailinglist archive it was suggested
-BEGIN PGP SIGNED MESSAGE-
Hello,
I just installed 5 CURRENT (20.1. snapshot) on a K6-2 500 whic was
previously running 4.4 STABLE without any problems but since CURRENT
is running, it keeps printing error messages about microuptime went
backwards which doesn't seem to hurt the system
I'm seeing a lot of this during heavy disk I/O (5 postmark benchmarks
running in parallel):
microuptime() went backwards (44525.3954411 - 44524.563978)
microuptime() went backwards (57425.4282241 - 57424.766121)
microuptime() went backwards (57425.4282241 - 57424.845844)
microuptime
On Wed, 19 Dec 2001, Matthew Dillon wrote:
I'm seeing a lot of this during heavy disk I/O (5 postmark benchmarks
running in parallel):
microuptime() went backwards (44525.3954411 - 44524.563978)
microuptime() went backwards (57425.4282241 - 57424.766121)
microuptime() went
:This has been asked on just about every FreeBSD list since the printf was
:added. Use the archives, man! :)
:
:This is when you have a device generating too much interrupt latency --
:enough to stall the RTC. Usually the offender is video cards, but in this
:case it could be your IDE
I've been seeing them a lot too on a recent (NOV) -current
On Wed, 19 Dec 2001, Matthew Dillon wrote:
I'm seeing a lot of this during heavy disk I/O (5 postmark benchmarks
running in parallel):
microuptime() went backwards (44525.3954411 - 44524.563978)
microuptime() went
Should I worry about this:
[...]
Aug 18 11:11:51 aldan /boot/mi/kernel: calcru: negative time of -1781452130 usec for
pid 352 (setiathome)
Aug 18 11:17:10 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 -
442731.165931)
Aug 18 11:17:10 aldan /boot/mi/kernel: microuptime
On Sat, 7 Oct 2000, Valentin Nechayev wrote:
At Fri, 6 Oct 2000 22:00:23 + (UTC), jhb wrote:
JB tc_windup() wasn't called soon enough to update the timecounter. Making
On my system _each_ boot causes hundreds of these messages.
And as described, long offsets without updating are
0xa00(167772160), microuptime is 1.4028290
mi_startup(): call subsystem 0xa80(176160768), microuptime is 1.4028701
mi_switch(): microuptime() went backwards (1.4029032 - 0.734106)
mi_switch(): microuptime() went backwards (1.4029032 - 0.734590)
mi_switch(): microuptime() went backwards (1.4029032
On 06-Oct-00 Valentin Nechayev wrote:
Following is partial dmesg output from 5.0(13)-CURRENT-20001002 kernel
with advanced debugging prints:
The problem was that the interrupt threads for the clk interrupt introduced
enough latency that occasionally (mostly during a heavy load of interrupts)
At Fri, 6 Oct 2000 22:00:23 + (UTC), jhb wrote:
JB The problem was that the interrupt threads for the clk interrupt introduced
JB enough latency that occasionally (mostly during a heavy load of interrupts)
JB tc_windup() wasn't called soon enough to update the timecounter. Making
On my
On 06-Oct-00 Valentin Nechayev wrote:
At Fri, 6 Oct 2000 22:00:23 + (UTC), jhb wrote:
JB The problem was that the interrupt threads for the clk interrupt
introduced
JB enough latency that occasionally (mostly during a heavy load of
interrupts)
JB tc_windup() wasn't called soon enough
On Wed, 20 Sep 2000, John Baldwin wrote:
On 19-Sep-00 Bruce Evans wrote:
It really does go backwards. This is caused by the giant lock preventing
the clock interrupt task from running soon enough. The giant lock can
also prevent the clock interrupt task from running often enough even
In message [EMAIL PROTECTED], John Baldwin writes:
As for the micruptime()
messages on boot, they only occur here on a UP kernel. On an SMP kernel I
don't get them. Also, they always occur during mi_switch() when an interrupt
thread is finishing and going back to sleep. The first such thread
John,
I get these on an SMP kernel, which locks up the box, I can't even
figure out where exactly its happening. Maybe I'm just missing something
in my kernel config file? I assumed (from UPDATING) that no real change
was
needed to the SMP options?
The hardware is an Intel N440BX
more info,
the N440BX has a symbios scsi card on board and an fxp card onboard.
I'm using relatively old scsi drives (4500 RPM seagates and HP drives)
I have softupdates on, and I'm now using COMPAT_OLDPCI for now, although I
only turned it back on after seeing that was the only real change I
On 19-Sep-00 Bruce Evans wrote:
On Tue, 19 Sep 2000, Andrey A. Chernov wrote:
With very latest kernel I got lots of
microuptime() went backwards (1.3624050 - 1.998840)
messages just before
Mounting root from ufs:/dev/da0s1a
It really does go backwards. This is caused
With very latest kernel I got lots of
microuptime() went backwards (1.3624050 - 1.998840)
messages just before
Mounting root from ufs:/dev/da0s1a
--
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cu
On Tue, 19 Sep 2000, Andrey A. Chernov wrote:
With very latest kernel I got lots of
microuptime() went backwards (1.3624050 - 1.998840)
messages just before
Mounting root from ufs:/dev/da0s1a
It really does go backwards. This is caused by the giant lock preventing
the clock interrupt
In message [EMAIL PROTECTED], Bruce Eva
ns writes:
On Tue, 19 Sep 2000, Andrey A. Chernov wrote:
With very latest kernel I got lots of
microuptime() went backwards (1.3624050 - 1.998840)
messages just before
Mounting root from ufs:/dev/da0s1a
It really does go backwards
On Wed, 20 Sep 2000, Bruce Evans wrote:
On Tue, 19 Sep 2000, Andrey A. Chernov wrote:
microuptime() went backwards (1.3624050 - 1.998840)
It really does go backwards. This is caused by the giant lock preventing
the clock interrupt task from running soon enough. The giant lock can
also
On Tue, Sep 19, 2000 at 08:30:25PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bruce Eva
ns writes:
On Tue, 19 Sep 2000, Andrey A. Chernov wrote:
With very latest kernel I got lots of
microuptime() went backwards (1.3624050 - 1.998840)
messages just before
for the remaining victims of the dreaded "microuptime
went backwards" message.
If you can reliably reproduce the problem, please contact me, so
we can arrange for some very detailed tracing to try to find out
what exactly is going on. I have not been able to trigger the
problem in my lab
Hello John Baldwin!
microuptime() went backwards (1.7682417 - 1.997434)
I recall reading in -current earlier this week that someone was
looking for victims getting this. What further information can I provide?
JB This is a SMPng issue on UP machines.
I have obtained the same on non-SMP
stuff
that's causing it.
Right, but you're not getting the 7 digit microsecond count, right?
You should contact phk.
Well, here is one of the messeges:
Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 -
10412, -694583121)
this is bad.. right ? :-)
Well
Steve Ames wrote:
Just upgraded to -CURRENT as of about noon (EST) today. At reboot
I got a lot of these:
microuptime() went backwards (1.7682417 - 1.997434)
I recall reading in -current earlier this week that someone was
looking for victims getting this. What further information can I
Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 -
10412, -694583121)y
this is bad.. right ? :-)
Well, at any rate it looks very funny. If this is a laptop, try
building a kernel without apm and see if that helps.
It only helps "hide" the problem
In message [EMAIL PROTECTED], Mike Smith writes:
Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 -
10412, -694583121)y
this is bad.. right ? :-)
Well, at any rate it looks very funny. If this is a laptop, try
building a kernel without apm and see
I have collected all the emails I've received and I have identified
at least two different causes:
There is a bogus i8254 implementation on certain Athlon Mobos, this
is a non-brainer since they should not use the i8254 but the TSC.
s/TSC/ACPI timer/
It might even work on those systems.
u/~culverk/|
=
On Fri, 8 Sep 2000, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Mike Smith writes:
Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 -
10412, -694583121)y
this is b
On Thu, 7 Sep 2000, John Baldwin wrote:
Most definitely an SMPng issue. If you take a SMP machine and compile a UP
and an SMP kernel on it, the SMP kernel will boot fine, whereas the UP kernel
will generate these warnings.
John,
not quite, I have an SMP box that I got these
Just upgraded to -CURRENT as of about noon (EST) today. At reboot
I got a lot of these:
microuptime() went backwards (1.7682417 - 1.997434)
I recall reading in -current earlier this week that someone was
looking for victims getting this. What further information can I provide?
-Steve
Steve Ames wrote:
Just upgraded to -CURRENT as of about noon (EST) today. At reboot
I got a lot of these:
microuptime() went backwards (1.7682417 - 1.997434)
I recall reading in -current earlier this week that someone was
looking for victims getting this. What further information can I
On Thursday, 7 September 2000 at 17:28:02 -0700, John Baldwin wrote:
Steve Ames wrote:
Just upgraded to -CURRENT as of about noon (EST) today. At reboot
I got a lot of these:
microuptime() went backwards (1.7682417 - 1.997434)
I recall reading in -current earlier this week that someone
Greg Lehey wrote:
On Thursday, 7 September 2000 at 17:28:02 -0700, John Baldwin wrote:
Steve Ames wrote:
Just upgraded to -CURRENT as of about noon (EST) today. At reboot
I got a lot of these:
microuptime() went backwards (1.7682417 - 1.997434)
I recall reading in -current earlier
On Thursday, 7 September 2000 at 17:48:06 -0700, John Baldwin wrote:
Greg Lehey wrote:
On Thursday, 7 September 2000 at 17:28:02 -0700, John Baldwin wrote:
Steve Ames wrote:
Just upgraded to -CURRENT as of about noon (EST) today. At reboot
I got a lot of these:
microuptime() went
The point I'm making is that we've had these problems before SMPng,
and that you can't automatically assume that it's SMPng just because
you get the messages. On the other hand, the 7 digits seem to be a
pretty reliable signature.
I'm getting this error while starting XFree86 4.0.1 on my
On Thursday, 7 September 2000 at 22:49:30 -0400, Kenneth Wayne Culver wrote:
The point I'm making is that we've had these problems before SMPng,
and that you can't automatically assume that it's SMPng just because
you get the messages. On the other hand, the 7 digits seem to be a
pretty
it.
Right, but you're not getting the 7 digit microsecond count, right?
You should contact phk.
Well, here is one of the messeges:
Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 - 10412,
-694583121)
this is bad.. right ? :-)
Well, at any rate it looks very funny
On Thursday, 7 September 2000 at 22:43:11 -0700, Mike Smith wrote:
Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 -
10412, -694583121)y
this is bad.. right ? :-)
Well, at any rate it looks very funny. If this is a laptop, try
building a kernel without apm
/sys/GENIUS i386
On Mon, Sep 04, 2000 at 06:41:14PM +0200, Poul-Henning Kamp wrote:
I'm looking for the remaining victims of the dreaded "microuptime
went backwards" message.
If you can reliably reproduce the problem, please contact me, so
we can arrange for some very detailed trac
genius.systems.pavilion.net 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Tue Sep 5
12:45:45 BST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENIUS
i386
On Mon, Sep 04, 2000 at 06:41:14PM +0200, Poul-Henning Kamp wrote:
I'm looking for the remaining victims of the dreaded "microuptime
On Wed, Sep 06, 2000 at 12:25:53PM +0200, Poul-Henning Kamp wrote:
Uhm, that is from the sound driver, not from the timecounter...
Poul-Henning
Oops, "You are in a maze of twisty passages all alike. Which direction
do you want to go?".
Joe
In message [EMAIL PROTECTED], Josef
I'm looking for the remaining victims of the dreaded "microuptime
went backwards" message.
If you can reliably reproduce the problem, please contact me, so
we can arrange for some very detailed tracing to try to find out
what exactly is going on. I have not been able to trigger t
66 matches
Mail list logo
