Really REALLY slow computer

Mon May 14 12:38:27 UTC 2007

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
another hurdle.

Steve.

----- Original Message -----
From: "D. Hugh Redelmeier" <hugh at mimosa.com>
Date: Saturday, May 12, 2007 5:53 pm
Subject: Re: Really REALLY slow computer
To: For users of Fedora <fedora-list at redhat.com>

> | From:  <zephod at 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 
> /proc/interrupts to
> | > 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.
>               CPU0       CPU1       
>      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, 
> ohci_hcd:usb2, ehci_hcd:usb3
>     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
>    ERR:          0
> 
> Normally the number of interrupts would be similar for each CPU but I
> have disabled the irqbalance service because it was causing problems.
> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399
> (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 
> the 
> | exact wording. It looks like a few characters and the end-of-line 
> are 
> | missing. I'm guessing that this is no big deal and that cat read 
> the 
> | 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 
> swoop, try:
>   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 
> processor. 
> | 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
> sentence:
>   LOC is the local interrupt counter of the internal APIC of every 
> CPU.
> | (Immediate isn't the right word as 
> | it takes ~45mins to boot and log in) Is this normal?
> 
> No.
> 
> -- 
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> 