![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Now there is something wrong here I guess...
-------------------------------------------------------------------------
top - 02:34:39 up 30 min, 2 users, load average: 1.10, 2.06, 1.70
Tasks: 137 total, 2 running, 128 sleeping, 0 stopped, 7 zombie
Cpu(s): 0.9%us, 22.4%sy, 0.5%ni, 75.1%id, 1.1%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 5993696k total, 996736k used, 4996960k free, 29212k buffers
Swap: 7847712k total, 0k used, 7847712k free, 850360k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8727 root 20 0 0 0 0 R 100 0.0 15:38.18 Xorg
5823 root 20 0 8528 1072 764 R 2 0.0 0:00.01 top
8751 root 20 0 120m 1344 900 S 2 0.0 0:00.57 rsyslogd
1 root 20 0 8072 756 624 S 0 0.0 0:00.93 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.02 migration/0
4 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/0
6 root RT -5 0 0 0 S 0 0.0 0:00.04 migration/1
7 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksoftirqd/1
8 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/1
9 root RT -5 0 0 0 S 0 0.0 0:00.03 migration/2
10 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksoftirqd/2
11 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/2
12 root RT -5 0 0 0 S 0 0.0 0:00.02 migration/3
13 root 15 -5 0 0 0 S 0 0.0 0:00.08 ksoftirqd/3
14 root RT -5 0 0 0 S 0 0.0 0:00.00 watchdog/3
-------------------------------------------------------------------------
It's worrying enough that Xorg is eating up 100% cpu power (fortunately
only a single of four cores).
What's even more worrying, however, is the fact that this was AFTER
issuing a tirade of "kill -SIGsome 8727" commands from root console...
AND a few "kill -9 8727" as well... WHAT THE...?!?
Is this some kind of Highlander process, that's immune to any fatal
wounds, and wants all the power for itself??
Looks like I'm doing something seriously wrong in my attempts to install
openSUSE. First try went good, but then I tried to resize and move
partitions around, apparently screwing things up. Now even complete
re-installs won't seem to screw things back down again, for /some/
obscure reason...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> Is this some kind of Highlander process, that's immune to any fatal
> wounds, and wants all the power for itself??
If something can't be killed with -9, you can be sure something in the
*kernel side* is causing problems.
A hung FUSE filesystem sometimes caused me such unkillable processes :/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> Is this some kind of Highlander process, that's immune to any fatal
> wounds, and wants all the power for itself??
That usually means it's in a kernel critical section. Altho I've never seen
it happen with a process that's at 100%. Usually it's blocked on a "fast"
kernel operation (i.e., anything you can't get back EINTR from) that just
never completed properly. In this case, I'd suspect it's busy-looping
probably somewhere in a driver.
In any case, it's clearly a kernel problem. Even when it's technically not
a kernel bug, it's a kernel misdesign wherein something that should be
interruptable (like a "fast open") winds up being slow because someone stuck
a network in the middle or something.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez schrieb:
> clipka wrote:
>> Is this some kind of Highlander process, that's immune to any fatal
>> wounds, and wants all the power for itself??
>
> If something can't be killed with -9, you can be sure something in the
> *kernel side* is causing problems.
>
> A hung FUSE filesystem sometimes caused me such unkillable processes :/
How can I tell whether a filesystem is running as FUSE?
Some other observations that may hint in a similar direction:
- The lockup occurs when I log in as a normal user, but when I log in as
root everything is shiny. Now the /home directories are actually on a
different partition. (fsck -f does not report anything suspicious for
that partition though.)
- Aside from Xorg eating a full core's power, I typically also see about
50% of another core's time being eaten by a process named
"hald-addon-stor", which I think can't be right either.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez schrieb:
> clipka wrote:
>> Is this some kind of Highlander process, that's immune to any fatal
>> wounds, and wants all the power for itself??
>
> If something can't be killed with -9, you can be sure something in the
> *kernel side* is causing problems.
>
> A hung FUSE filesystem sometimes caused me such unkillable processes :/
Well, whatever the underlying reason was, it is gone, hopefully for
good; most likely one of the following fixed it:
- Changed screen resolution from 800x600 @ 16bit to 1280x1024 @ 24bit.
In my first install attempt I had set the resolution to 1280x1024 right
from the start, but in the subsequent install attempts I was lazy about it.
- Moved all the contents of the user's home directory into a
subdirectory thereof. As mentioned already, /home resides on a separate
partition, and wasn't rebuilt from scratch during the subsequent install
attempts.
I tend to suspect the latter, actually.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka <ano### [at] anonymous org> wrote:
> Looks like I'm doing something seriously wrong in my attempts to install
> openSUSE.
why do you even try? You know Linux doesn't like you a bit. ;)
hey, I wish I had that much memory! :D
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> Nicolas Alvarez schrieb:
>> clipka wrote:
>>> Is this some kind of Highlander process, that's immune to any fatal
>>> wounds, and wants all the power for itself??
>>
>> If something can't be killed with -9, you can be sure something in the
>> *kernel side* is causing problems.
>>
>> A hung FUSE filesystem sometimes caused me such unkillable processes :/
>
> How can I tell whether a filesystem is running as FUSE?
Probably you would have started it yourself.
A FUSE filesystem runs in a user-space program. It's often used for network-
based filesystems, like "ftpfs".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez schrieb:
>> How can I tell whether a filesystem is running as FUSE?
>
> Probably you would have started it yourself.
>
> A FUSE filesystem runs in a user-space program. It's often used for network-
> based filesystems, like "ftpfs".
Then... probably no. It's a fresh installation, and I didn't knowingly
start anything exotic. Unless using ext3 instead of ext4 would be
considered exotic.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |