From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-May/015764.html | 170 ++++++++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-May/015764.html (limited to 'zarb-ml/mageia-dev/2012-May/015764.html') diff --git a/zarb-ml/mageia-dev/2012-May/015764.html b/zarb-ml/mageia-dev/2012-May/015764.html new file mode 100644 index 000000000..fd26f61ea --- /dev/null +++ b/zarb-ml/mageia-dev/2012-May/015764.html @@ -0,0 +1,170 @@ + + + + [Mageia-dev] Strange system stalls - neep a tip + + + + + + + + + +

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

+ Mahmut Bulut + mahmutbulut0 at gmail.com +
+ Mon May 21 23:17:05 CEST 2012 +

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

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1