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() w
> >: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.
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
>
> :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 backwards (748.912755 -> 748.237402)
>microupt
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.159612)
I also th
: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
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 also see these messages on my Dell 410 Workstation at work and a Dual
PIII Box I use at home to do builds with...they just seem to 'come and go'
with no particular pattern to them...I have just been ignoring them for the
most part...they don't really seem to cause any problems..
At 06:54 P
16 matches
Mail list logo