Re: Really REALLY slow computer

[Steve Blackwell]

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

2. The LOC line has some large numbers; ~1500000 for each processor. 
This is immediately after boot up, (Immediate isn't the right word as 
it takes ~45mins to boot and log in) Is this normal?

I have updated to FC7T4 and I am now running the 2.6.21-1.3116 kernel 
which someone suggested would correct the problem but it did not. I 
have also tried with acpi=off as a kernel option but that didn't 
change anything either.

HP dc7700p, 2G RAM, 2x250G

Steve

Really REALLY slow computer

[Tim]

On Tue, 2007-05-01 at 06:17 -0700, zephod(a)cfl.rr.com wrote:
>  This is immediately after boot up, (Immediate isn't the right
> word as 
>  it takes ~45mins to boot and log in) Is this normal?  
Forty-five minutes?  NO!

My systems, ranging in abilities and enable services, take two to three
minutes from cold boot to useability.  The truly awful boxes might take
five minutes.

-- 
(This box runs FC6, my others run FC4 & FC5, in case that's
 important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

Really REALLY slow computer

[Steve Blackwell]

----- Original Message -----
From: Tim <ignored_mailbox(a)yahoo.com.au&gt;
Date: Tuesday, May 1, 2007 10:57 pm
Subject: Re: Really REALLY slow computer
To: For users of Fedora <fedora-list(a)redhat.com&gt;

>  On Tue, 2007-05-01 at 06:17 -0700, zephod(a)cfl.rr.com wrote:
>  > This is immediately after boot up, (Immediate isn't the right 
>  word as 
>  > it takes ~45mins to boot and log in) Is this normal? 
>  
>  Forty-five minutes?  NO! 
Yup, 45 mins!

It starts to boot OK but really bogs down when it gets to INIT and then
udev times out which takes about 10mins. I was hoping the 2.6.21 kernel
was going to help but it did not. Everything seems to function OK when
it finally boots but it juuussssttt ttttoooo ssslllooowwww. AAAAGGGGHHHH!

Steve
>  
>  My systems, ranging in abilities and enable services, take two to 
>  threeminutes from cold boot to useability.  The truly awful boxes 
>  might take
>  five minutes.
>  
>  -- 
>  (This box runs FC6, my others run FC4 & FC5, in case that's
>  important to the thread.)
>  
>  Don't send private replies to my address, the mailbox is ignored.
>  I read messages from the public lists.
>  
>  
>  -- 
>  fedora-list mailing list
>  fedora-list(a)redhat.com
>  To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>

Really REALLY slow computer

[Mikkel]

> >> This is immediately after boot up, (Immediate isn't the
> right 
> > word as it takes ~45mins to boot and log in) Is this normal? 
> > Forty-five minutes?  NO!
>  
>  Yup, 45 mins!
>  
>  It starts to boot OK but really bogs down when it gets to INIT and then
>  udev times out which takes about 10mins. I was hoping the 2.6.21 kernel
>  was going to help but it did not. Everything seems to function OK when
>  it finally boots but it juuussssttt ttttoooo ssslllooowwww. AAAAGGGGHHHH!
>   
Is there anything in the logs about timeouts during boot?
/var/log/dmesg may have some clues...

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

Really REALLY slow computer

[Mogens Kjaer]

zephod(a)cfl.rr.com wrote:
...
>  HP dc7700p, 2G RAM, 2x250G 
...

I've had nothing but frustrations getting Linux
to run on a dc7700. I gave up.

You can find more suggestions on HP's forums.

Mogens

-- 
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: [phone], Fax: [phone]
Email: mk(a)crc.dk Homepage: http://www.crc.dk

Really REALLY slow computer

[D. Hugh Redelmeier]

| From:  <zephod(a)cfl.rr.com&gt;
| 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 might
not 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.

Really REALLY slow computer

[Steve Blackwell]

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(a)mimosa.com&gt;
Date: Saturday, May 12, 2007 5:53 pm
Subject: Re: Really REALLY slow computer
To: For users of Fedora <fedora-list(a)redhat.com&gt;

>  | From:  <zephod(a)cfl.rr.com&gt;
>  | 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(a)redhat.com
>  To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>

Really REALLY slow computer

[potat0]

Upgraded my dc7700p to BIOS 2.10 Rev. A (19 Apr 2007) and everything
runs smooth. (Booting in maybe 15 secs... used to be 30 mins :)

Tor Egil


-- 
This is an email sent via The Fedora Community Portal https://fcp.surfsite.org
https://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=191218&t...
If you think, this is spam, please report this to webmaster(a)fcp.surfsite.org and/or blame
trefsahl(a)gmail.com.