On Mon, Aug 26, 2002 at 04:30:19PM -0400, Brian T. Schellenberger wrote:
| Mine's a laptop with APM enabled (BIOS + kernel).
But on the other hand mine's a laptop with APM and it doesn't have the
problem. Then again, my kernel is vintage July 19.
For people seeing this problem with
Patrick Thomas wrote:
2. What is to be done ? I have no reason to believe this won't crop up on
4.6.2 or later...does anyone else ?
I just saw it happen on today's -CURRENT on the same laptop (has ACPI).
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
Lars Eggert wrote:
I just saw it happen on today's -CURRENT on the same laptop (has ACPI).
And hit send too soon, there's another datapoint. When it happens on
-CURRENT, the rtc at irq8 is happily ticking along.
Also, unlike the subject, top does not show all zeroes: the interrupt
and idle
In message [EMAIL PROTECTED],
Patrick
Thomas writes:
And more important;y, does anyone know _why_ it is happening and what it
means for a system affected ?
I had this occur once. As it turned out, one of the clocks in the clock
chip was hooped. Replacing the motherboard fixed the problem.
Ok, this seems to have died down a bit, and my own urgency has passed
since it is no longer manifesting itself on my test machinehowever,
two things come to mind:
1. is it possible that arbitrary top output is now suspect on machines
that have manifested this behavior ? I am not showing
On Wed, Aug 28, 2002 at 11:55:14PM -0700, Patrick Thomas wrote:
rtc irq8 29272122 66
and I am seeing a rate of 128 on normal systems. So maybe my top output
is still wrong, even though it isn't all zeros.
rtc irq8 753070128
The problem
On Sun, Aug 25, 2002 at 04:49:23PM -0700, Patrick Thomas wrote:
Also, just to add a bit more info, sometimes instead of rebooting to solve
the problem, the problem doesn't exist, and rebooting causes it to
manifest. So it seems fairly random.
Can you watch vmstat -i before and after the
ok:
# vmstat -i
interrupt total rate
ata0 irq14 23 0
ahc0 irq10 15 0
aac0 irq2 6330470 30
fxp0 irq517556113 83
fdc0 irq6 4 0
sio0 irq4
Patrick Thomas wrote:
Now, when I repeat vmstat -i, all of these numbers (or rather, all of the
large numbers) increase _except_ for `rtc irq8`.
interrupt total rate
mux irq114851 12
ata0 irq14 94219240
atkbd0 irq1
ok, after 2+ days, for no discernible reason I now have real top stats
back.
This has occurred within the last 20 minutes, and I have done nothing at
all on the system save normal operation. vmstat -i now tells me:
# vmstat -i
...
rtc irq8 479105 2
...
The 497105
Patrick Thomas wrote:
ok, after 2+ days, for no discernible reason I now have real top stats
back.
This has occurred within the last 20 minutes, and I have done nothing at
all on the system save normal operation. vmstat -i now tells me:
# vmstat -i
...
rtc irq8
On Monday 26 August 2002 12:00 pm, Lars Eggert wrote:
| Patrick Thomas wrote:
| Now, when I repeat vmstat -i, all of these numbers (or rather, all
| of the large numbers) increase _except_ for `rtc irq8`.
|
| interrupt total rate
| mux irq114851
On Mon, Aug 26, 2002 at 11:02:50AM -0700, Peter Wemm wrote:
This has happened before. For some reason, the RTC stops sending the 128Hz
statclock (statistics clock) interrupts. One way to unwedge that in the past
was to break into ddb and do a 'show rtc' command.. but that is hardly a
I will note that my system is a dual processor system, no APM hardware in
it, and I have an identical machine running a kernel built from an
identical kernel configuration file running an identical FreeBSD system
that has _never_ had the problem.
On Mon, 26 Aug 2002, Bruce M Simpson wrote:
No, world and kernel out of sync is _not _ the problem in my case - I made
4.6.1-RC2 diskettes and did a ftp installation - so there was no upgrading
involved.
Further, this is an intermittent problem - sometimes it happens, sometimes
it doesn't. I think some people have reported it on non RC2
It's usually gone after a reboot. Haven't debugged it further since I
saw now other problems.
Yes, but other times it is not manifesting, and it _starts_ after a
reboot.
Also, concerning solving the problem with a reboot, although my system is
merely a test machine, I am fairly certain that
On Sunday 25 August 2002 06:07 pm, Patrick Thomas wrote:
| It's usually gone after a reboot. Haven't debugged it further since
| I saw now other problems.
|
| Yes, but other times it is not manifesting, and it _starts_ after a
| reboot.
|
| Also, concerning solving the problem with a reboot,
Well, the actual *release* versions *are* supposed to be reliable for
mission-critical applications. The purpose of the RC and STABLE
versions being to find problems so that they don't make it to the
release versions.
A lofty goal, indeed. However it has been pointed out that this
18 matches
Mail list logo
