You are not logged in.
hi.
it happenned the first time with some app (i don't know which one) using the hard disk quite intensively.
and then i couldn't even move my mouse. well i move it but 10 seconds later the pointer move on the screen. and i coudn't do anything under X. even type something.
i manage to go to a console via CTRL-ALT-F1. but couldn't login because login give me a time-out ! and then i finally rebooted so i could get back my system and use it.
then,later, i decided to run dd if=/dev/urandom of=/somepartition bs=1024 before setting up a crypted partition. and it happened again !
the hard-disk activity and the 100% CPU usage . and i couldn't do again anything except reboot !!
when i run the same dd command on my Arch 32 bits. it does give 100% CPU usage too but i can still use X without problem. even without any slow down.
so the 32bits system is an old Athlon XP 1800+ with an IDE disk.
and the Arch64 is a brand new Athlon 64 X2 4400+ with a SATA drive and a nforce chipset MCP61.
so what is the cause of that ? clearly the cpu is so used that nothing could work. but on the 32bits system too. and it still works. so ?
is the configuration of the kernel of arch64 different from arch32 ?
i am thinking at compiling my own kernel with PREEMT configured or even compiled an rt kernel. but why is this needed whereas on the 32bit arch all is fine ???
Offline
Hi
Open a console and type in top, now you can see the processes.
On top of this program is the process with highest cpu use.
Ps: Sorry for my bad english
Offline
i told you i couldn't even do that "open a console".
and by the way the 2nd time,i knew it was dd that use the 100% cpu.
Offline
may be that's bs=1024 the problem and what that caused the slowdown ?
or may be i mistyped /dev/urandom and used /dev/random ?
i am using now :
schedtool -B -e dd if=/dev/urandom of=/somepartition
and it works nice. no more than 50% CPu usage. and no slowdown...
the schedtool -B is to be sure there will be no freeze and that dd will not take all the cpu power...
Offline