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
Hello again,
When i originally posted this, it was _highly_ OT. the machine in question
runs windows ME, but i figured the best place to find hardware gurus was
here.
the topic has rather degraded, and while i enjoy getting mail from alan,
the fact that it has nothing to do with me dampens the
I may be off base here, but the problem as described below does _NOT_
seem to be OT so I removed that from the subject line. A clock drift
change with an OS update is saying _something_ about the OS, not the
hardware. In this case it seems to be the 2.4.x OS that is loosing
time. I suspect the
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
> > 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
Alan Cox <[EMAIL PROTECTED]> writes:
> Suppose vesafb did something like this, dropping the printk lock
>
> if(test_and_set_bit(0, _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
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 context so
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
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
every
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 from interrupt
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 the
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 machine clock slides
I may be off base here, but the problem as described below does _NOT_
seem to be OT so I removed that from the subject line. A clock drift
change with an OS update is saying _something_ about the OS, not the
hardware. In this case it seems to be the 2.4.x OS that is loosing
time. I suspect the
Hello again,
When i originally posted this, it was _highly_ OT. the machine in question
runs windows ME, but i figured the best place to find hardware gurus was
here.
the topic has rather degraded, and while i enjoy getting mail from alan,
the fact that it has nothing to do with me dampens the
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 (tm).
The alternative
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
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
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
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
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 (many)
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
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 the drivers which
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
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 using USB
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 of ntp are you using?
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
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 only
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
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,
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
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
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).
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).
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
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 show up
"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 thoughts on
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
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 thoughts
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
the
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
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
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, the
clock is
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
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
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
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
57 matches
Mail list logo
