On Tuesday 12 February 2008, Eben King wrote:
> I think parallelizing bootable drive checking would require a threaded
> BIOS. Much more complex and hence buggier.
Only if you read it, which of course windows is.
> > When you say it's using up your CPU how do you identify this?
>
> Well, given that top doesn't lie it must not be that. Maybe something's
> hogging a vital syscall?
>
> eben@pc:~$ time xterm -e bash -c exit
>
> real 0m5.029s
> user 0m0.011s
> sys 0m0.005s
I get subsecond responses
> Try it on your machine. It should take way short, maybe <0.1s.
> trn-in-an-xterm takes a long time to start also. The CPU speed is pegged
> at max, but that's because cpufreq_ondemand was set up improperly. (It's
> fixed temporarily now, but should I just put the commands into rc.local or
> is there some holy Debian way?)
I got Gutsy gibbon on the machine I ran the above on.
> > Often times a machine look like it has locked up but is actually in some
> > deep processing which is using up some resource making the desktop appear
> > locked up.
>
> Few things have failed outright ("rxvt -e true" and "rxvt -e :" hang, but
> "rxvt -e bash" works eventually), they're just slow starting. Can't think
> of something I have which puts a load on the CPU during operation. Some
> games stress the GPU.
I don't think your issue is CPU related per se. It certainly sounds like
either a misconfiguration or conflicting library or similar. Assuming you
still have usable RAM left and not swapping.
--Steve Szmidt
"They that would give up essential liberty for temporary safety deserve neither liberty nor safety." Benjamin Franklin ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:00:41 EDT