|
Bugzilla – Full Text Bug Listing |
| Summary: | System crashes to black screen and switchoff silently after coredump of kded, drkonqi and akonadi hanging? | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Stakanov Schufter <stakanov> |
| Component: | Kernel | Assignee: | E-mail List <kernel-maintainers> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | stakanov, wbauer |
| Version: | Leap 42.3 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 42.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | I join an expert between to crashes to reboot during todays operations. The cut is from reboot to crash. | ||
As the crashes do happen now less frequently, but do happen, I wanted to join that there is a link with an action and with a program. The action is suspend to disk. The program is powerdevil. Often before going completely black after resume and a short while of working, I see that powerdevil does/has crash(ed). As the system comes down immediately I do not have any backtrace. I also notice that, on changing with ctrl+alt+fn, often when I come to a specific desktop the screen is dimmed down in backlighting, this happens also without notice or necessity during work, without any action. This is not extremely frequent however (once every 10 sessions ca). If the system resumes normally it happens that, after 10 or 15 minutes of work, if you change user with alt+cntrl+fn, can come down with all desktops, only the vent is running. The change to tty1 shows a completely black screen then. The system will then after 10 seconds switch off. Hi Fabian, would you please take a look at this issue? I'm not sure whether it is right to assign it to you, please feel free to reassign whenever necessary, thank you! > During this crash you will notice a flickering yellow stripe on the left side of the monitor. This will turn to complete black after a few secs. The system will then run for about 30 seconds and eventually shutdown also silently. + > At the current status, doing important work in this machine is risky business. 42.2 was stable in this regards. makes a kernel issue likely. Try again after uninstalling "drm-kmp-default", mkinitrd and rebooting. I did this, I uninstalled drm-kmp package time ago. Otherwise the system would have presented the issues as of bug: Bug 1051115 SDDM in new install only partially functional (input window and user selection). Crashes if no selection is done. Since I have uninstalled that package, I can use normally sddm and all users. Provided you are not writing an email with kmail/kontact. Then happens what I describe here. So the issue is directly triggered by using kmail/kontakt writing a mail, in a mixed IMAP/POP setup. One user IMAP one user POP. All folders mailing lists. Without starting the program, I do not(!) get the blackout it seems. So this speaks against the kernel. However for the kernel speaks the fact that since the latest update (with BT security fix, so the current one) the issues has become much more unstable. I did write in factory list a mail if somebody experiences the same issue, a few days ago. (A positive note is, the bug I reported about the head-set not working in BT seems to be solved now, after that update, I am still checking and will then comment on it on the respective bug). I have now installed the kmail package from Wolfgang Bauer https://download.opensuse.org/repositories/home:/wolfi323:/branches:/OBS_Maintained:/kmail/openSUSE_Leap_42.3_Update/ So far the result is: - crashes: since the install I do not experience crashes any more - doubles: since the install I do not experience duplication any more - multiple merge candidates: since the install I do not experience multiple merge candidates. - crashes after suspend to disc: not experienced any more - system load: up to 20°C less for the CPU - popup of "do not know were the filter belongs to..." are gone. bugs left: sometimes, to tell the truth very rarely, that is, if you shift between folders while the system receives new mail and filtering is going on, a part (maybe 2 or 4 out of about 10 e.g. messages) stay in arrival. If the filter (apply all filters to that folder) is selected, the messages are filtered correctly and to the correct folders. If I would ever say something that could get better, then this would be the speed and system load when filtering. It has to be noted though that I am also filtering with clavav and spamassassin which may be part of the lengthy process encountered. Can be up to a minute before ending, in the mean you have 30 seconds for a complete filter run. I have currently 23 filters running. All in all that package changes my life quality. Seriously. With it I get my work done. (In reply to Stakanov Schufter from comment #5) > I have now installed the kmail package from Wolfgang Bauer > https://download.opensuse.org/repositories/home:/wolfi323:/branches:/ > OBS_Maintained:/kmail/openSUSE_Leap_42.3_Update/ Actually I rather expected it to help with bug#1054205... But if it fixes both your bug reports, we should mark one as duplicate of the other. I'd prefer to use the other one though, as that actually mentions kmail in the subject. Also, that patch definitely doesn't fix a system crash, it merely fixes a filtering problem in kmail that apparently triggered other problems for you (due to heavy system load maybe?). But if those crashes doesn't happen any more, there's no point in keeping this bug report open either I suppose. And I just saw that you also filed bug#1055818 about powerdevil crashing, which was mentioned here as well. Please close that one too if it no longer happens. *** This bug has been marked as a duplicate of bug 1054205 *** |
Created attachment 736379 [details] I join an expert between to crashes to reboot during todays operations. The cut is from reboot to crash. I try to describe this bug as good as I can. As it does not give clear logs. Several users have reported similar problems on the mailing lists. Log into a system with several users. The crash happens to a 70% with a certain user (can trigger) but also without in similar conditions. It is very difficult to discern if there a two bugs or one bug. a) after a suspend to ram, when the system is recalled, it will run normal operation but crash silently after doing a few user changes with ctl+tty. b) the crash can happen also silently and unexpectedly after some time of work in the same user. c) the crash can be greatly accelerated and triggered if in one user kontact is open. A hallmark for knowing that kded will crash soon is the blocking of kontact while retrieving messages. The akonadi indexes also corrupt on a regular base, this seems however be greatly worsened by the continuous crashes. The crash is in one time, silent. The screen goes black, no cursor. You have several applications to core dump in journalctl. Fist to dump is kded always. Second is konqui (which never pops up btw) and kontact. Prior to the crash you notice slowness of the system. Occupation of 100% of the cpu1, raise of temperature from 50 to 70 then to 90 degrees, first with one cpu, then with the second. (This is a core2duo ironlake with corei5 - an X201). Ksysguard shows msql and akonadi occupying up to 25% of CPU time when it happens. But no process seem to be responsible for the 100%. When going into a third user and killing with sigterm in ksysguard the responsible users processes, strangely the kontact/akonadi session of another user is shut down too. Sometimes sigterm will not suffice. Kmail, akonadi or msql will stay as zombie. Sigkill will do. However often then after a few time the silent crash will happen. During this crash you will notice a flickering yellow stripe on the left side of the monitor. This will turn to complete black after a few secs. The system will then run for about 30 seconds and eventually shutdown also silently. When restarting the file system does not seem to be hit by this, no check is requested in EXT4. No data loss occur but in akonadi with regularly compromised indexes. Emptying cache does help. Akonadictl stop, akonadictl fsck does not seem to work as it never comes back to prompt. This was tried waiting also for about 1 day before closing the terminal in question. The terminal then complaining about the process being still running. At the current status, doing important work in this machine is risky business. 42.2 was stable in this regards.