} > } The fbdev console problem is too horrible to pretend to solve by resyncing
} > } on timer interrupts. At least for the x86 the fix is to sort out the fb
} > } locking properly
} >
} > How close is that?
}
} Its not in itself a big problem, but since it doesnt reformat your hard disk,
}
> We have the same trouble on PPC but we make sure to re-sync on each
> interrupt. We can see several lost timer interrupts after a ^L in emacs
> running on the fb console. The resync lets us catch up on those interrupts
> (and not lose time) but we still spend a lot of time not servicing
>
> } The fbdev console problem is too horrible to pretend to solve by resyncing
> } on timer interrupts. At least for the x86 the fix is to sort out the fb
> } locking properly
>
> How close is that?
Its not in itself a big problem, but since it doesnt reformat your hard disk,
explode randomly
On 28 Feb 2001 23:37:40 +, Andrew Morton wrote:
> Eric Buddington wrote:
> >
> > I know this has been reported on the list recently, but I think I can
> > provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
> > running at 250. This system has no history of clock problems.
> >
} > We have the same trouble on PPC but we make sure to re-sync on each
} > interrupt. We can see several lost timer interrupts after a ^L in emacs
} > running on the fb console. The resync lets us catch up on those interrupts
} > (and not lose time) but we still spend a lot of time not
We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
interrupts.
Eric Buddington wrote:
>
> I know this has been reported on the list recently, but I think I can
> provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
> running at 250. This system has no history of clock problems.
>
> adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01
I know this has been reported on the list recently, but I think I can
provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
running at 250. This system has no history of clock problems.
adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
conditions.
flipping
I know this has been reported on the list recently, but I think I can
provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
running at 250. This system has no history of clock problems.
adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
conditions.
flipping
Eric Buddington wrote:
I know this has been reported on the list recently, but I think I can
provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
running at 250. This system has no history of clock problems.
adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in
We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
interrupts.
} We have the same trouble on PPC but we make sure to re-sync on each
} interrupt. We can see several lost timer interrupts after a ^L in emacs
} running on the fb console. The resync lets us catch up on those interrupts
} (and not lose time) but we still spend a lot of time not servicing
}
On 28 Feb 2001 23:37:40 +, Andrew Morton wrote:
Eric Buddington wrote:
I know this has been reported on the list recently, but I think I can
provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
running at 250. This system has no history of clock problems.
} The fbdev console problem is too horrible to pretend to solve by resyncing
} on timer interrupts. At least for the x86 the fix is to sort out the fb
} locking properly
How close is that?
Its not in itself a big problem, but since it doesnt reformat your hard disk,
explode randomly or
We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
} } The fbdev console problem is too horrible to pretend to solve by resyncing
} } on timer interrupts. At least for the x86 the fix is to sort out the fb
} } locking properly
}
} How close is that?
}
} Its not in itself a big problem, but since it doesnt reformat your hard disk,
} explode
16 matches
Mail list logo
