Andrew Morton wrote:
>
> Alan Cox wrote:
> >
> > > > queued_writes=1;
> > > > return;
> > > > }
> > > > }
> > >
> > > Unfortunately, that means that if machine crashes in interrupt, it may
> > > "loose" printk message. That is considered bad
On Mon, 12 Feb 2001, Alan Cox wrote:
> > > queued_writes=1;
> > > return;
> >
> > Just what happens when you run out of dmesg ring in an interrupt ?
>
> You lose a couple of lines. Big deal. I'd rather lose two lines a year on
> a problem (and the dmesg ring
Alan Cox wrote:
>
> > > queued_writes=1;
> > > return;
> > > }
> > > }
> >
> > Unfortunately, that means that if machine crashes in interrupt, it may
> > "loose" printk message. That is considered bad (tm).
>
> The alternative is that the m
> > queued_writes=1;
> > return;
> > }
> > }
>
> Unfortunately, that means that if machine crashes in interrupt, it may
> "loose" printk message. That is considered bad (tm).
The alternative is that the machine clock slides continually and
Hi!
> > > Why are interrupts being disabled for vesafb scrolling anyway ?
> >
> > Console writes happen under spin_lock_irq(console_lock).
> >
> > The only reason for this which I can see: the kernel
> > can call printk() from interrupt context.
>
> We certainly need to be able to call printk
> > queued_writes=1;
> > return;
>
> Just what happens when you run out of dmesg ring in an interrupt ?
You lose a couple of lines. Big deal. I'd rather lose two lines a year on
a problem (and the dmesg ring buffer is pretty big) than two minutes an hour
e
Alan Cox <[EMAIL PROTECTED]> writes:
> Suppose vesafb did something like this, dropping the printk lock
>
> if(test_and_set_bit(0, &vesafb_lock))
> {
> if(in_interrupt())
> {
> // remember which bit of the dmesg ring to queue
>
> > Why are interrupts being disabled for vesafb scrolling anyway ?
>
> Console writes happen under spin_lock_irq(console_lock).
>
> The only reason for this which I can see: the kernel
> can call printk() from interrupt context.
We certainly need to be able to call printk from interrupt contex
Alan Cox wrote:
>
> > Hmm, I can make it loose 30 seconds in 12 seconds. Just cat
> > /etc/termcap. Vesafb does this kind of stuff. [Yes, 3 times slower
> > clock].
>
> Why are interrupts being disabled for vesafb scrolling anyway ?
Console writes happen under spin_lock_irq(console_lock).
The
> Hmm, I can make it loose 30 seconds in 12 seconds. Just cat
> /etc/termcap. Vesafb does this kind of stuff. [Yes, 3 times slower
> clock].
Why are interrupts being disabled for vesafb scrolling anyway ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sun, Feb 11, 2001 at 12:06:14PM +0100, Pavel Machek wrote:
>
> > > > > >I've discovered that heavy use of vesafb can be a major source of clock
> > > > > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> > > > >
> > > > > This is extremely interesting. What version
Pavel Machek wrote:
>
> > > Vesafb is happy to block interrupts for half a second.
> >
> > And has this been observed to cause clock drift?
>
> YEs. I've seen time running 3 times slower. Just do cat /etc/termcap
> with loaded PCI bus. Yesterday I lost 20 minutes during 2 hours -- I
> have been
Hi!
> > > > >I've discovered that heavy use of vesafb can be a major source of clock
> > > > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> > > >
> > > > This is extremely interesting. What version of ntp are you using?
> > >
> > > Is vesafb one of the drivers which
Pavel Machek wrote:
>
> Hi!
>
> > > >I've discovered that heavy use of vesafb can be a major source of clock
> > > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> > >
> > > This is extremely interesting. What version of ntp are you using?
> >
> > Is vesafb one of th
Hi!
> I've discovered that heavy use of vesafb can be a major source of clock
> drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> system (similar Hw/Sw configuration to yours), a 2.4 kernel "make dep"
> from a vesafb console will cause the system clock to drift 10-12
>
Hi!
> > >I've discovered that heavy use of vesafb can be a major source of clock
> > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> >
> > This is extremely interesting. What version of ntp are you using?
>
> Is vesafb one of the drivers which blocks interrupts for
Hi!
> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't show up anything worthwhile in the first couple of
>
Hacksaw wrote:
>
> >I've discovered that heavy use of vesafb can be a major source of clock
> >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
>
> This is extremely interesting. What version of ntp are you using?
Is vesafb one of the drivers which blocks interrupts fo
On Sun, 4 Feb 2001, Tom Eastep wrote:
> Thus spoke Michael B. Trausch:
>
> > On Sat, 3 Feb 2001, Josh Myer wrote:
> >
> > > Hello all,
> > >
> > > I know this _really_ isn't the forum for this, but a friend of mine has
> > > noticed major, persistent clock drift over time. After several weeks, t
On Sun, 04 Feb 2001 10:31:35 -0500, you wrote:
>Technical explanations aside, some sort of clock drift exists in all
>computers. My experience with Sun hardware, for instance, was that the
>hardware and software clocks rarely agreed.
>
>You should set up your machines to use some sort of time s
Thus spoke Hacksaw:
> >I've discovered that heavy use of vesafb can be a major source of clock
> >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
>
> This is extremely interesting. What version of ntp are you using?
>
The RH7 rpm -- ntp-4.0.99k-5
-Tom
--
Tom Eastep
>I've discovered that heavy use of vesafb can be a major source of clock
>drift on my system, especially if I don't specify "ypan" or "ywrap". On my
This is extremely interesting. What version of ntp are you using?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
Thus spoke Michael B. Trausch:
> On Sat, 3 Feb 2001, Josh Myer wrote:
>
> > Hello all,
> >
> > I know this _really_ isn't the forum for this, but a friend of mine has
> > noticed major, persistent clock drift over time. After several weeks, the
> > clock is several minutes slow (always slow). Any
Technical explanations aside, some sort of clock drift exists in all
computers. My experience with Sun hardware, for instance, was that the
hardware and software clocks rarely agreed.
You should set up your machines to use some sort of time synchronization
software, such as ntp or rdate. When
"Michael B. Trausch" wrote:
>
> On Sat, 3 Feb 2001, Josh Myer wrote:
>
> > Hello all,
> >
> > I know this _really_ isn't the forum for this, but a friend of mine has
> > noticed major, persistent clock drift over time. After several weeks, the
> > clock is several minutes slow (always slow). Any
On Sat, 3 Feb 2001, Josh Myer wrote:
> Hello all,
>
> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't sho
Josh Myer <[EMAIL PROTECTED]> writes:
> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't show up anything w
Hello all,
I know this _really_ isn't the forum for this, but a friend of mine has
noticed major, persistent clock drift over time. After several weeks, the
clock is several minutes slow (always slow). Any thoughts on the
cause? (Google didn't show up anything worthwhile in the first couple of
pa
28 matches
Mail list logo
