Bug 2775

maybe there is something in /var/log/Xorg.0.log

CC: (none) => thierry.vignaud

@ Frédéric

Is this bug still valid for current cauldron?

Keywords: (none) => NEEDINFO
CC: (none) => marja11

(In reply to comment #2)
> Is this bug still valid for current cauldron?

Unfortunately, yes. This bug makes me crazy. And the problem is that it's not 100% reproducible (I would say the bug happens in 50% of cases). I wonder if it freezes when something else is interacting with MageiaUpdate which prevents it to complete its task.

Keywords: NEEDINFO => (none)

(In reply to comment #3)
> (In reply to comment #2)
> > Is this bug still valid for current cauldron?
> 
> Unfortunately, yes. This bug makes me crazy. And the problem is that it's not
> 100% reproducible (I would say the bug happens in 50% of cases). I wonder if it
> freezes when something else is interacting with MageiaUpdate which prevents it
> to complete its task.

(In reply to comment #0)

> In case this is useful, the command eating a lot of CPU was:
> 
>   /etc/X11/X :0 vt8 -nr -nolisten tcp -auth /var/run/xauth/A:........

so you never have a problem when logging in to a text terminal instead of graphic and updating from there?

I meant booting into run level 1 and then updating

However, it is interesting, too, what happens when you're in X, go to a konsole and update from there (# urpmi --auto-update)

It was never with another application that your memory was eaten?

(In reply to comment #1)
> maybe there is something in /var/log/Xorg.0.log

I saw you never replied to that question, can attach that log, or the old log, if it didn't happen again after the old log was made.

I'll try to remember to use the graphical tool to update cauldron, next time. 

The only thing I can find about " /etc/X11/X :0 vt8 -nr -nolisten tcp -auth /var/run/xauth/A... ", is a Mandriva bug report https://qa.mandriva.com/show_bug.cgi?id=59673, where someone says kdm caused it.

Would it be possible, that the update tool sometimes first tries to display the updates on a different video terminal than where you really are?

On ctrl + alt + F"what" are you when it happens, and on ctrl + alt + F"what" are you when it doesn't happen?

I had too much imagination:

I just updated updated cauldron and one, using the applet.

cauldron was on vt 7: no problems
1 was on vt 8: no problems

so which vt you're on doesn't seem to make any difference

@ Frédéric

Which version of x11-server src.rpm are you using?

If you're not yet using version 1.11.2-3, please try whether upgrading helps.

(this question is because of bug 2600, where one user reported upgrading from x11-server-1.10.4.mga2.src.rpm to x11-server-1.11.2-3.mga2.src.rpm solved his problem of X using too much CPU)

(In reply to comment #4)
> so you never have a problem when logging in to a text terminal instead of
> graphic and updating from there?

I never tried that and didn't really plan to do this. :)


(In reply to comment #6)
> However, it is interesting, too, what happens when you're in X, go to a konsole
> and update from there (# urpmi --auto-update)

I think it always worked fine.


> It was never with another application that your memory was eaten?

The same problem exists with rpmdrake.


> > maybe there is something in /var/log/Xorg.0.log
> I saw you never replied to that question

I see nothing special in this file.


(In reply to comment #8)
> Which version of x11-server src.rpm are you using?

x11-server-xorg-1.11.2-3.mga2

Because of bug 2600, and because lebarhon said that in cauldron his X was on "alt ctrl F1", in this thread https://forums.mageia.org/en/viewtopic.php?f=15&t=1609&start=50, i'd again like to know where you're X is when this happens.

Just in case it matters, anyway ;)

rpmdrake-5.27-1.mga2.src.rpm is the version you use? (it contains MageiaUpdate, too, btw)

what is the output of: lspcidrake -v | fgrep Card ?

Source RPM: mgaonline => rpmdrake-5.27-1.mga2.src.rpm, x11-server-1.11.2-3.mga2.src.rpm

What would be interesting would to log from a remote connection then run "strace -p <pid_of_Xorg>" while starting rpmdrake.

Created attachment 1564 [details]
do not flush more than 3 times a second

Also does this patch help?
as root, just run the following commands in a terminal to apply it:

cd /
patch -p0 < /where/it/was/downloadd/less-flushing.diff

we could also try to call XFlush() instead of gdk_flush() (which is more costly)

Testing that now...

Ping?

I wanted to wait a few days before reporting back to you, just to get better data. Since you applied your patch, the freeze time disappeared, so it seems the problem is indeed fixed. Thank you! :)

Closing then

Status: NEW => RESOLVED
Resolution: (none) => FIXED

*** Bug 3480 has been marked as a duplicate of this bug. ***

CC: (none) => zen25000

I have just tested this in a clean LXDE installation of i586 Cauldron Beta, fully updated.
After opening rpmdrake via mcc using all GUI from the task bar icon the problem is still there.
I booted this installation over 30 mins ago, and went almost immediately into rpmdrake to test.
It's still sat there with the cpu at 95% and no package menu displayed.
Here's the state of play :-

[baz@jackodesktop ~]$ rpm -q rpmdrake
rpmdrake-5.30-1.mga2

[baz@jackodesktop ~]$ top

top - 18:37:11 up 4 min,  1 user,  load average: 1.01, 0.85, 0.40
Tasks: 101 total,   2 running,  98 sleeping,   0 stopped,   1 zombie
Cpu(s): 95.7%us,  3.3%sy,  0.0%ni,  1.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1030124k total,   409268k used,   620856k free,    19292k buffers
Swap:  4095468k total,        0k used,  4095468k free,   168732k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 1368 root      20   0 69124  14m 8904 R 93.6  1.4   2:37.94 X                  
 1941 root      20   0 99.3m  78m  16m S  2.0  7.8   0:10.76 rpmdrake           
 1982 baz       20   0  211m  12m 9.9m S  1.3  1.2   0:00.37 lxterminal         
   28 root      20   0     0    0    0 S  0.3  0.0   0:00.30 kworker/0:2        
  283 root      20   0     0    0    0 S  0.3  0.0   0:00.25 kworker/0:3        
  852 root      20   0  5864 1248 1052 S  0.3  0.1   0:00.05 hald-addon-inpu    
 1854 baz       20   0 51224  32m  11m S  0.3  3.2   0:01.73 net_applet         
    1 root      20   0  5372 3372 1868 S  0.0  0.3   0:00.72 systemd            
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd           
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/0        
    4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kworker/0:0        
    5 root      20   0     0    0    0 S  0.0  0.0   0:00.21 kworker/u:0        
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0        
    7 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset             
    8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper            
    9 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs          
   10 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 netns

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Created attachment 1740 [details]
sample of strace of X during hang

A few seconds of strace output of X pid

Created attachment 1741 [details]
A sample of strace of rpmdrake during hang

A few seconds of strace out put of rpmdrake pid

I just discovered that collapsing and re-opening the mcc window by clicking it's taskbar item twice clears the hang and the rpmdrake left panel immediately fills.

Thierry - if there is anything else that I can supply in relation to this please ask as this really needs fixing before mga2 release.

This i586 test system seems to exhibit the problem about 50% of the time and while it's hung I can still run Firefox, top, strace etc.

I have just clean installed Beta 2 x86_64 full KDE and the issue is still there.
Rpmdrake is useless like this.
Increasing to high priority - but really it should be release blocker.

Priority: Normal => High

Assigning to maintainer

@ Thierry

Is it OK to use the same bug report, btw, I suppose the cause can't be the same?

Keywords: NEEDINFO => (none)
Assignee: bugsquad => thierry.vignaud

No it's not OK.
Yes it's probably another issue

That specific issue is fixed.
Please do not mix different issues.
Open a new bug report.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

I was not aware that it is a different issue, but if you really want me to copy / paste all the above into another bug I will.

NO hang on - my original bug was Bug 3480 which *you* marked as a duplicate of this one. That's how I ended up here in the first place.

I already did all this twice - so I'm not doing it again.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

In that case, reopen bug 3480, not this one.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

@ Barjac

I'll clone 3480 and copy what you posted here, just give me some time

(In reply to comment #29)
> @ Barjac
> 
> I'll clone 3480 and copy what you posted here, just give me some time

it is bug 5000