Hide Forgot
Created attachment 840462 [details] dmesg in the report directory Description of problem: With several WARNINGs in a row, abrt is not getting the first for the report, thus not allowing to send report due to tainted flag. Version-Release number of selected component (if applicable): abrt-2.1.10-1.fc20.x86_64 abrt-addon-kerneloops-2.1.10-1.fc20.x86_64 How reproducible: Don't know. Just got this sequence once. Actual results: Only one report is show in abrt, but it's not reportable due to the tainted flag. Expected results: The report has the information from the first WARNING, thus is not tainted.
Created attachment 840463 [details] backtrace in the report directory
Reproduces still in Rawhide as well (kernel-headers-3.14.0-0.rc2.git4.1.fc21.x86_64, abrt-addon-kerneloops-2.1.12-2.fc21.x86_64). Taint GW should not block reporting of a bug as it means GPL-only, warning has occurred. FWIW apparently 512 is the numerical value for warning. taint should probably be nor'd against this or something when checking for eligibility
IANAKH, but I guess the taint flag means there may be rubbish even in this case of a WARN and GPL only modules, so I'm OK with it not being reportable. The real problem here is that there is a series of WARNs, and abrt is not getting the first, untainted, reportable one that provokes them all.
(In reply to Seppo Yli-Olli from comment #2) > Reproduces still in Rawhide as well > (kernel-headers-3.14.0-0.rc2.git4.1.fc21.x86_64, > abrt-addon-kerneloops-2.1.12-2.fc21.x86_64). > Taint GW should not block reporting of a bug as it means GPL-only, warning > has occurred. I'm sorry, but that's not true. ABRT must not allow you to report koops with W flag. https://github.com/abrt/abrt/wiki/FAQ#wiki-what-is-tainted-kernel-and-why-is-my-kernel-tainted (In reply to Máximo Castañeda from comment #3) > The real problem here is that there is a series of WARNs, and abrt is not > getting the first, untainted, reportable one that provokes them all. Thank you for the report! I managed to reproduce this behaviour on my machine and it's definitely a bug, because ,as you said, ABRT has to save the first untainted oops.
Sorry I hadn't updated on reproducibility. I have been keeping a kernel with which I can trigger a bug that generates a cascade of warnings so that I could test an update of abrt. So you have another test point here, although an unreliable one, as sometimes abrt does get the first untainted warning.
(In reply to Máximo Castañeda from comment #5) Thanks! We know what is the root cause of this bug, and we are working on a proper fix. There is a race condition which causes that the first detected oops is processed after consecutive oops are done.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
If the abrt-dump-oops finds for example 5 oopses at a time, it creates 5 dump dirs one by one and when the each dump dir is created abrt-server is informed about it. abrt-server can do the post-create event only on one detected problem at a time. When abrt-server starts process the event it creates lock "post-create.lock" in an abrt working directory (/var/spool/abrt). And here is the problem, abrt-server starts process the first problem and before it locks the dump dir the process is suspended by operating system. So abrt-server can starts process not first occurred problem and here is the race condition. If the abrt-server process the not first oops, it removes all other problems as duplicate so the first one (reportable) is removed. We must teach abrt (abrt-dump-journal-oops) to inform abrt-server about next created problems after the first one is locked.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
it's still present in Fedora 24 and in general, abrt should ignore the "GW" taint flags, they certainly don't mean that Fedora kernel developers are missing information on how to debug the issue
(In reply to Hubert Kario from comment #10) > and in general, abrt should ignore the "GW" taint flags, they certainly > don't mean that Fedora kernel developers are missing information on how to > debug the issue Well, I don't think we need more Bugzilla bugs opened by ABRT and not allowing the "GW" oops'es going to Bugzilla was requested by kernel folks. The oops'es tainted with "GW" together with all other opss'es can be found at: https://retrace.fedoraproject.org/faf/problems/?associate=__None&type=kerneloops
so, how am I supposed to file a bug that the kernel was "W" tainted, if the warning or ooops that caused it automatically taints it?! (the first warning issued by kernel already has the "W" taint flag)
(In reply to Hubert Kario from comment #12) Once we fix the race condition described in comment #8, the first detected oops should not be "W" taited. I've just opened a pull request that should fix it: https://github.com/abrt/abrt/pull/1164
no, I said that I had situations in which the first warning, as reported by dmesg, already reports a "W" tainted kernel
(In reply to Hubert Kario from comment #14) > I had situations in which the first warning, as reported by > dmesg, already reports a "W" tainted kernel As I understand it, that shouldn't happen and it would be kernel bug, not abrt. I think the logs shown by dmesg can be cleared, does it also contain the last boot? If so, I'd open a kernel (or module that causes the warning) bug.
Reporting of tainted oops'es should be possible in the future (bug #1351297). How it happens that your kernel is "W" tainted by default? /proc/sys/kernel/tainted should hold 0 by until something causes a warning (if you don't use proprietary modules). Are you sure that the warning does not modify kernel in a way that it generates oops-es that would never be possible otherwise?
(In reply to Máximo Castañeda from comment #15) > (In reply to Hubert Kario from comment #14) > > I had situations in which the first warning, as reported by > > dmesg, already reports a "W" tainted kernel > > As I understand it, that shouldn't happen and it would be kernel bug, not > abrt. > I think the logs shown by dmesg can be cleared, does it also contain the > last boot? If so, I'd open a kernel (or module that causes the warning) bug. yes, the dmesg haven't overflowed, it included everything since the boot it might have been a kernel bug (I had this situation like this 2 years ago, it went away after few upgrades before I was able to properly debug it), point is, that those two flags are not robust enough to completely reject any oopses that include them it causes frustration and bad user experience (In reply to Jakub Filak from comment #16) > Reporting of tainted oops'es should be possible in the future (bug #1351297). > > How it happens that your kernel is "W" tainted by default? > /proc/sys/kernel/tainted should hold 0 by until something causes a warning > (if you don't use proprietary modules). yes, now I know, but then it was a case of "what's the point of the flag if the warning that causes it complains about it?!" > Are you sure that the warning does not modify kernel in a way that it > generates oops-es that would never be possible otherwise? not sure if I understand... I had a kernel, it was misbehaving, the dmesg included few warnings that ended with an oops, all those messages, including the very first one, included the "W" flag.
(In reply to Hubert Kario from comment #17) > I had a kernel, it was misbehaving, the dmesg included few warnings that > ended with an oops, all those messages, including the very first one, > included the "W" flag. And all those oopses could be a consequence of the problem that made kernel "W" tainted but without direct relation to the problem (maybe, the problem touched memory that it should not). Or maybe, there is a possibility to taint kernel with "W" without printing oops. Thus ABRT would detected only "W" tainted oops'es. Anton, is my assumption above correct?
Jakub, you're correct. Tainted with W kernel must have the prior warning message in the log, this message is reported, any consequent message is ignored. If you see the kernel tainted with W without any prior message that caused that taint - share the dmesg log here. Anton.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.