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 lap
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 i
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
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 probl
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 has
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 all
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:
>
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
> sol
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
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
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 n
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:
# 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
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
>
> 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 p
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, a
> 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
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
18 matches
Mail list logo
