CentOS - Jul 2012 - problem with machine "freezing" for short periods

I have two HP dc7800 convertible minitowers that are exhibiting the
following issue: every 5-10 minutes, they will "freeze" for about 30
seconds, and then pick right back up again. During the freeze, it seems
that nothing at all happens on the system; the clock doesn't even advance
(it just picks up again with the next second, and that 30-or-so seconds
are lost).

I've tried both CentOS 5.8 and 5.7, thinking it was a kernel
incompatibility, but the problem happened with both versions. I have tried
different hard drives, different memory, even swapped the entire machine,
and the problem exists everywhere. I have tried adding "pci=nommconf"
to
the kernel line, as that was reported as being necessary back with 5.2 on
these machines, but that made no difference (and shouldn't be necessary
now, anyway, as I believe the issue has either been fixed or
worked-around).

I am stuck, and can't figure out where to even suspect the problem might
actually be. There are no errors getting logged anywhere that I can find,
probably because everything just "stops" temporarily, so there's
nothing
for the system to log.

Does anyone have any idea where I could look to fix this? I think I am
next going to go back to 5.2, where the pci=nommconf is necessary, because
at least back that far it appears to have been working for other people.
However, I really would like to have this running 5.8.

Thanks!

---
Mike VanHorn
Senior Computer Systems Administrator
College of Engineering and Computer Science
Wright State University
265 Russ Engineering Center
937-775-5157
michael.vanhorn at wright.edu
http://www.cecs.wright.edu/~mvanhorn/

Vanhorn, Mike wrote:
>
> I have two HP dc7800 convertible minitowers that are exhibiting the
> following issue: every 5-10 minutes, they will "freeze" for about
30
> seconds, and then pick right back up again. During the freeze, it seems
> that nothing at all happens on the system; the clock doesn't even
advance
> (it just picks up again with the next second, and that 30-or-so seconds
> are lost).
>
> I've tried both CentOS 5.8 and 5.7, thinking it was a kernel
> incompatibility, but the problem happened with both versions. I have tried
> different hard drives, different memory, even swapped the entire machine,
> and the problem exists everywhere. I have tried adding
"pci=nommconf" to
> the kernel line, as that was reported as being necessary back with 5.2 on
> these machines, but that made no difference (and shouldn't be necessary
> now, anyway, as I believe the issue has either been fixed or
> worked-around).
<snip>
When you say "swapped the entire machine", what did you do? Also,
what's
running on them? Have you tried running top -d 10 or smaller (that will
update the screen every 10 secs; I only recently found that current top
allows tenths of a second.

If you don't see anything, I'd suggest you call HP, assuming they're
still
under warranty.

      mark

On 07/25/2012 04:34 PM, Vanhorn, Mike wrote:
> I have two HP dc7800 convertible minitowers that are exhibiting the
> following issue: every 5-10 minutes, they will "freeze" for about
30
> seconds, and then pick right back up again. During the freeze, it seems
> that nothing at all happens on the system; the clock doesn't even
advance
> (it just picks up again with the next second, and that 30-or-so seconds
> are lost).
I've several HP dc7x00 machines, and I've never seen that problem
with centos 5 or 6.

Do you also see the problem if you boot in runlevel 3, i.e. without X?

Mogens

-- 
Mogens Kjaer, mk at lemo.dk
http://www.lemo.dk

On Wed, 25 Jul 2012, Vanhorn, Mike wrote:

*snip*
> I am stuck, and can't figure out where to even suspect the problem
might
> actually be. There are no errors getting logged anywhere that I can find,
> probably because everything just "stops" temporarily, so
there's nothing
> for the system to log.
>
> Does anyone have any idea where I could look to fix this? I think I am
> next going to go back to 5.2, where the pci=nommconf is necessary, because
> at least back that far it appears to have been working for other people.
> However, I really would like to have this running 5.8.
Hi Mike. Are you on 32 or 64 bits ?

If 32 bit you might like to take a look at this here, which 
I compiled and packaged for Centos 5.5 32 bit - works on 5.8 
OK as well:

Package Signing Key:
www.karsites.net/centos/downloads/5.6/karsites-GPG-public-key-2011-03-18.asc

32 bit binary RPM:
www.karsites.net/centos/downloads/5.6/qps-1.9.18.6-1.i386.rpm

Fedora 6 source code I rebuilt qps from:
www.karsites.net/centos/downloads/5.6/qps-1.9.18.6-1.fc6.src.rpm

If you click on the %MEM or %CPU headings, this will 
toggle the sort order of the running processes by highest to 
lowest and v/v for those headings - same applies to the 
other headings.

Kind Regards,

Keith Roberts

-----------------------------------------------------------
Websites:
http://www.karsites.net
http://www.php-debuggers.net
http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with
TMDA [http://tmda.net]
-----------------------------------------------------------

On 7/25/12 10:34 AM, "Vanhorn, Mike" <michael.vanhorn at
wright.edu> wrote:
>
>I have two HP dc7800 convertible minitowers that are exhibiting the
>following issue: every 5-10 minutes, they will "freeze" for about
30
>seconds, and then pick right back up again. During the freeze, it seems
>that nothing at all happens on the system; the clock doesn't even
advance
>(it just picks up again with the next second, and that 30-or-so seconds
>are lost).
>
>I've tried both CentOS 5.8 and 5.7, thinking it was a kernel
>incompatibility, but the problem happened with both versions. I have tried
>different hard drives, different memory, even swapped the entire machine,
>and the problem exists everywhere. I have tried adding
"pci=nommconf" to
>the kernel line, as that was reported as being necessary back with 5.2 on
>these machines, but that made no difference (and shouldn't be necessary
>now, anyway, as I believe the issue has either been fixed or
>worked-around).
>
>I am stuck, and can't figure out where to even suspect the problem might
>actually be. There are no errors getting logged anywhere that I can find,
>probably because everything just "stops" temporarily, so
there's nothing
>for the system to log.
>
>Does anyone have any idea where I could look to fix this? I think I am
>next going to go back to 5.2, where the pci=nommconf is necessary, because
>at least back that far it appears to have been working for other people.
>However, I really would like to have this running 5.8.
>
>Thanks!

As a followup, I've determined that it is network related, but I'm still
not sure what the problem is. I did go back to CentOS 5.2, but the problem
still exists with that version, too.

Basically, what seems to be happening is that the network freezes around
30 seconds, and then picks right back up. There are no errors in any logs
that I can find, and process that are running locally and that only depend
on local resources keep right on going and don't have a problem.

I have tried using a different network card (as opposed to the one on the
motherboard), but the problem happens with that, too. It almost has to be
a configuration issue, or a BIOS settting, but I don't get it.

---
Mike VanHorn
Senior Computer Systems Administrator
College of Engineering and Computer Science
Wright State University
265 Russ Engineering Center
937-775-5157
michael.vanhorn at wright.edu
http://www.cecs.wright.edu/~mvanhorn/

It turned out to be something very simple, but which wasn't obvious to
check to begin with. There was another computer (a Windows machine) that
was supposed to have been taken out of service a long time ago, but
someone has recently put it back on the network. Because it was supposed
to have been no longer used, it's IP address was re-allocated (a year and
a half ago!) to the machine that I have been agonizing over all week.

On someone's suggestion, I decided to put the problem PC on a different
subnet, because we thought it might be something amiss with the new
networking hardware that was installed a month or so ago, and suddenly the
problem went away. Some more investigation, and we discovered that the IP
address was still being used, and, thus, stumbled across the actual
problem.

Thank you to all who responded!

It's always the simplest things, in the last place you look...

---
Mike VanHorn
Senior Computer Systems Administrator
College of Engineering and Computer Science
Wright State University
265 Russ Engineering Center
937-775-5157
michael.vanhorn at wright.edu
http://www.cecs.wright.edu/~mvanhorn/