[Mageia-dev] Strange system stalls - neep a tip

[Mahmut Bulut]

probably ntpd won't cause something like this, this is not a botnet
attack :) and also situation can't caused from cpu usage. I think it
can be (and your thought i appreciate) is kernel-related problem.
And use a c code something like that to panic;

char *kernel_panic = NULL;
char message = *kernel_panic;

and build a kernel extension after this use insmod to load kernel ext.
reboot and wait for panicking.
after panicking fall into terminal mode(if you can't, you can do it on
next reboot)
if you saw your system.map or where the log happens something like
"warn_slowpath_common+0x***" this can be caused by your eax and pc's
async work (program counter) your specific problem and it is not
caused by any distro but you can submit your trace to kernel
developers for debugging purposes and will be fixed.

2012/5/21, Robert Fox <list at foxconsult.net>:
> On Mon, 2012-05-21 at 19:50 +0200, David Sjölin wrote:
>> On Mon, May 21, 2012 at 7:33 PM, AL13N <alien at rmail.be> wrote:
>> > perhaps check the logs (/var/log/messages) for information regarding
>> > those
>> > downtimes.
>> >
>> > see if the ping also delays
>> >
>> > perhaps try to monitor something via ssh or in tty, to see if it's only
>> > the graphic card.
>> >
>> > also, check ntpd settings, do they make big jumps?
>> >
>> > etc...
>> >
>> >
>> > in short: logging is always the key.
>> >
>> >> Hello All -
>> >>
>> >> I am experiencing a strange problem with a specific machine running
>> >> Cauldron.  I am beginning to believe it is NOT a Mageia problem
>> >> because
>> >> when I boot into Ubuntu 12.04 the problem exists as well.  I think it
>> >> may be hardware related but I can not find what is causing this issue.
>> >>
>> >> The machine is an Acer Aspire x3900 with a quad core ‎AMD Phenom(tm)
>> >> II
>> >> X4 925 Processor - 6GB memory.  GeForce GT215 (GeForce 320) card. I am
>> >> running the x86_64 version of Cauldron.
>> >>
>> >> The problem occurs under both KDE and Gnome
>> >>
>> >> Basically, the system seems to freeze up (mouse moves) but nothing
>> >> else
>> >> - gkrellem freezes and no errors occur - it just seems to hang - but
>> >> magically wake up again after some time (many seconds at a time)
>> >>
>> >> I have checked various logs and can not find any problems - so I am
>> >> stumped how to find the source of the problem.  I leave the machine
>> >> running 24x7, but don't think it is a thermal issue.
>> >>
>> >> When the system runs under Windows 7 (64bit) it appears to run fine.
>> >>
>> >> Any hints what I could check?
>> >>
>>
>> Hello!
>>
>> If you want to log cpuusage to see if some process has extra high cpu
>> usage during this freeze you could do something like:
>>
>> while true; do date >> testfilen.txt ; top -b -n1 >> testfilen.txt ;
>> sleep 1; done
>>
>> Then you will get top-output every second (sleep 1) or whatever time
>> you specify for sleep. I think there is a way to do this with top
>> only, without the delay but not sure which flags to use then (possibly
>> top -d 1 -b)
>>
>> The file testfilen.txt will of course grow quite large after a while,
>> so you can't keep this running 24/7 maybe, but maybe you could clear
>> out the file regularly until you get the error situation again and
>> then based on the date output you should be able to find cpu usage
>> around the time of the problem.
>>
>> Regards,
>>
>> David
>
> Thanks for the quick responses.  I checked the cpu usage, but there
> doesn't appear to be a spike - and the load average in htop is real low:
>
> load average: 0.46, 0.67, 0.56
>
> so if the X server or something else was maxing out the cpu, I'd see
> that.
>
> Also, if I use a console in KDE (like yakuake) - the stalls happen in
> there as well.  At first I though this was Firefox related (like flash
> problem or something) because it was most noticeable when I surfed -
> firefox freezes off and on and it is really frustrating.
>
> This machine was working fine for at least a year - and I was suspecting
> something with the latest kernels and the AMD processor - but have no
> evidence.
>
> The search continues . . .
>
> Thanks again,
> R.Fox
>
>
>
>