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 -&
On Sun, 17 Feb 2002, Matthew Dillon wrote:
> 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
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 DELL255
:
: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 o
> >: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.
> 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.
>
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,
: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: port 0x8b0-0x8bf at device 15.1 on
pci0
Uh huh.
It might be possible
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 sys
>
> :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
: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 screwed.
: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.
If the _safe version works I'
> 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 p
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 t
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 bac
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 generatio
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.15
: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 en
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
runni
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 ty
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 remo
: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
At 06:54 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)
>
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)
> ...
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)
eps printing error 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
-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 s
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 ->
: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 controlle
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.76
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.84584
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: microupt
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
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 so
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 s
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)
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 bac
On 20-Sep-00 Siobhan Patricia Lynch wrote:
> 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
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 made
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 motherbo
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 th
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 e
On Tue, 19 Sep 2000 18:40:43 +0400, "Andrey A. Chernov" wrote:
> With very latest kernel I got lots of
>
> microuptime() went backwards (1.3624050 -> 1.998840)
>
> messages just before
I've also seen them for the first time with today's kernel.
Inter
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:/de
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
> >>
> >>
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 en
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
>>
>>
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 l
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 f
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 abl
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
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
wam.umd.edu/~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 ->
&g
>
> 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 sys
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 thi
> > 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.
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
gt;
> >>> I'm getting this error while starting XFree86 4.0.1 on my laptop computer,
> >>> and I'm using FreeBSD 4.1-STABLE, so I'm sure it's not the SMP stuff
> >>> that's causing it.
> >>
> >> Right, but yo
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.
ing XFree86 4.0.1 on my laptop computer,
>>> and I'm using FreeBSD 4.1-STABLE, so I'm sure it's not the 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 ? :-)
=
| Kenneth Culver | FreeBSD: The best NT upgr
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
>> pre
> 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
boot
>>>> 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 p
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 backwar
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 re
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 ge
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
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 Ka
M +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 tra
L 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
> went backwards" message.
>
> If you can reliably reproduce the problem, please
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
72 matches
Mail list logo
