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@xxxxxxxxxx> Date: Saturday, May 12, 2007 5:53 pm Subject: Re: Really REALLY slow computer To: For users of Fedora <fedora-list@xxxxxxxxxx> > | From: <zephod@xxxxxxxxxx> > | 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@xxxxxxxxxx > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list >
