I got my HP7700p machine working about a week ago and I posted what I
had done but now that I look back in the archives, my message does not
show up so I'll repeat the message.
It turned out to be a BIOS issue. This machine is a brand new machine
purchase in April but the BIOS version was v1.05. The latest version is
x.10 (I'll get to the x. part in a minute) which was released in April
but the previous version was v1.09 released in Dec 2006 so I was
suprised to see v1.05 on my machine.
When I went to the HP site to download the new BIOS, I found that there
were 2 versions; a v1.10 version and a v2.10 version. The 2.xx series is
for vPro machines and the 1.xx is for non-vPro machines. Mine is a vPro
and yet it had the 1.xx BIOS installed.
I upgraded to the v2.10 BIOS. That version of the BIOS also came with a
microcode update whaich I also installed.
The result was a normal speed machine, yea!! I don't now if it was the
.10 version of the BIOS, the microcode upgrade, changing from the 1.xx
series to the 2.xx series of BIOS or some combination of all of them
that did the trick but it works just fine now.
Now I'm just waiting for the xen kernel to get to the 2.6.21 series so I
can take a look at virtualization. The 2.6.20 xen kernel won't boot.
Also, I don't see any BIOS options for virtualization so that might be
----- Original Message -----
From: "D. Hugh Redelmeier" <hugh(a)mimosa.com>
Date: Saturday, May 12, 2007 5:53 pm
Subject: Re: Really REALLY slow computer
To: For users of Fedora <fedora-list(a)redhat.com>
| From: <zephod(a)cfl.rr.com>
| Date: Tue, 01 May 2007 06:17:05 -0700
[Sorry for the slow reply. I only read the list once in a while.]
| D. Hugh Redelmeier wrote
| > Sometimes machines run slowly due to being swamped by unhandled
| > interrupts. It would be interesting to monitor
| > see if this is happening.
| I don't know what I'm looking for
That would be a good reason to post your results for us to analyze.
Here's an example from my HP Pavilion a1430n (Athlon x2). It has only
been up for 50 minutes due to some instability that surfaced recently.
1: 8377 0 Phys-irq-level i8042
7: 0 0 Phys-irq-level parport0
8: 0 0 Phys-irq-level rtc
9: 0 0 Phys-irq-level acpi
12: 105 0 Phys-irq-level i8042
14: 54503 0 Phys-irq-level ide0
17: 1 0 Phys-irq-level ATI IXP
19: 184369 0 Phys-irq-level ohci_hcd:usb1,
20: 23823 0 Phys-irq-level peth0
21: 401938 0 Phys-irq-level ohci1394, bttv0
22: 105640 0 Phys-irq-level libata
256: 524111 0 Dynamic-irq-level timer0
257: 84851 0 Dynamic-irq-level resched0
258: 26 0 Dynamic-irq-level callfunc0
259: 0 112101 Dynamic-irq-level resched1
260: 0 123 Dynamic-irq-level callfunc1
261: 0 300198 Dynamic-irq-level timer1
262: 91 0 Dynamic-irq-level xenbus
263: 0 0 Dynamic-irq-level console
NMI: 0 0
LOC: 0 0
Normally the number of interrupts would be similar for each CPU but I
have disabled the irqbalance service because it was causing problems.
(I added comments #64 and #6.8).
| but there are 2 things that I
| noticed about the contents of the /proc/interrupts file:
| 1. when I typed 'cat /proc/interrupts' I got a message saying
| something like 'file not terminated correctly'. I don't remember
| exact wording. It looks like a few characters and the end-of-line
| missing. I'm guessing that this is no big deal and that cat read
| file in the middle of an update.
The file is created "on demand". When you try to read from it, the
contents are generated and never actually sit on a disk or the like.
What you are observing does not normally happen. cat reads in 1K
chunks and the only observable cracks ought to be at 1K boundaries
(assuing that /proc/interrupts code locks kernel structures, which
mightnot be the case). If you want to try to read in one fell
dd if=/proc/interrupts bs=1024k
I would guess that userland is being starved for processor cycles
which could expose some race conditions.
| 2. The LOC line has some large numbers; ~1500000 for each
| This is immediately after boot up,
I don't really know what LOC counts. If you look in the kernel source
tree, in Documentation/filesystems/proc.txt, you will see this brief
LOC is the local interrupt counter of the internal APIC of every
| (Immediate isn't the right word as
| it takes ~45mins to boot and log in) Is this normal?
fedora-list mailing list
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list