Many of us need akmods for our hardware.
But when the kernel crashes or ooops'es, we are unable to send the crash report.
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
At least provide a way for us to send them to the place we got them from, namely rpmfusion in this case, or other repos in other cases.
All abrt has to do is ask for the user's login id and password and have it submit the report there.
On 03/16/2015 09:44 AM, jd1008 wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I've been thinking the same thing. If nothing else, whoever is assigned to the bug should try to recreate the crash on a stock machine with no kmods and work on it if they succeed.
Recreating a rare crash even when you know the exact conditions that caused the crash is very very difficult. I have been involved in not so rare crashes (we had some machines of the exact same hw type that all crashed randomly about 1x per week). And duplicating that crash tied up a test machine for >30 days before finally duplicated the crash, as we were not able to exactly duplicate the load condition that caused the crash. Typically the crashes are dealt with is by noticing a pattern and using that pattern to try to determine the nature of the failure and how common it is. With a single crash you have no idea if it as a hardware fault or not.
Given the number of crashes we are probably talking about and the number of different kernel versions you are talking about one would need to have an almost infinite hardware budget to even possibly run the test.
On Mon, Mar 16, 2015 at 11:58 AM, Joe Zeff joe@zeff.us wrote:
On 03/16/2015 09:44 AM, jd1008 wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I've been thinking the same thing. If nothing else, whoever is assigned to the bug should try to recreate the crash on a stock machine with no kmods and work on it if they succeed.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 03/16/2015 11:29 AM, Roger Heflin wrote:
Recreating a rare crash even when you know the exact conditions that caused the crash is very very difficult. I have been involved in not so rare crashes (we had some machines of the exact same hw type that all crashed randomly about 1x per week). And duplicating that crash tied up a test machine for >30 days before finally duplicated the crash, as we were not able to exactly duplicate the load condition that caused the crash. Typically the crashes are dealt with is by noticing a pattern and using that pattern to try to determine the nature of the failure and how common it is. With a single crash you have no idea if it as a hardware fault or not.
Given the number of crashes we are probably talking about and the number of different kernel versions you are talking about one would need to have an almost infinite hardware budget to even possibly run the test.
On Mon, Mar 16, 2015 at 11:58 AM, Joe Zeff joe@zeff.us wrote:
On 03/16/2015 09:44 AM, jd1008 wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I've been thinking the same thing. If nothing else, whoever is assigned to the bug should try to recreate the crash on a stock machine with no kmods and work on it if they succeed.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
I do not mean to discredit you Roger, but I did kernel development and debugging for almost 40 years, starting with the AT&T version 3 Unix. It is not as you say.
If it is a obvious bug, yes those are easy to find, the obvious bugs also have lots of crashes tainted or untainted. The ones that always get everyone in trouble are the ones were something modifies something unrelated to it and causes someone else's code to crash in a bizarre way.
On Mon, Mar 16, 2015 at 12:56 PM, jd1008 jd1008@gmail.com wrote:
On 03/16/2015 11:29 AM, Roger Heflin wrote:
Recreating a rare crash even when you know the exact conditions that caused the crash is very very difficult. I have been involved in not so rare crashes (we had some machines of the exact same hw type that all crashed randomly about 1x per week). And duplicating that crash tied up a test machine for >30 days before finally duplicated the crash, as we were not able to exactly duplicate the load condition that caused the crash. Typically the crashes are dealt with is by noticing a pattern and using that pattern to try to determine the nature of the failure and how common it is. With a single crash you have no idea if it as a hardware fault or not.
Given the number of crashes we are probably talking about and the number of different kernel versions you are talking about one would need to have an almost infinite hardware budget to even possibly run the test.
On Mon, Mar 16, 2015 at 11:58 AM, Joe Zeff joe@zeff.us wrote:
On 03/16/2015 09:44 AM, jd1008 wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I've been thinking the same thing. If nothing else, whoever is assigned to the bug should try to recreate the crash on a stock machine with no kmods and work on it if they succeed.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
I do not mean to discredit you Roger, but I did kernel development and debugging for almost 40 years, starting with the AT&T version 3 Unix. It is not as you say.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 03/16/2015 10:58 AM, Joe Zeff wrote:
On 03/16/2015 09:44 AM, jd1008 wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I've been thinking the same thing. If nothing else, whoever is assigned to the bug should try to recreate the crash on a stock machine with no kmods and work on it if they succeed.
Thank you Joe! We need to collect some user steam behind this need.
On Mon, Mar 16, 2015 at 09:58:54AM -0700, Joe Zeff wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I've been thinking the same thing. If nothing else, whoever is assigned to the bug should try to recreate the crash on a stock machine with no kmods and work on it if they succeed.
That's a lot of obligation to put onto someone you are not paying. The kernel maintainers have a huge and constantly growing pile of work. I don't think it's unreasonable to ask for bug submitters to recreate the crash on a stock system.
On 03/16/2015 01:46 PM, Matthew Miller wrote:
That's a lot of obligation to put onto someone you are not paying. The kernel maintainers have a huge and constantly growing pile of work. I don't think it's unreasonable to ask for bug submitters to recreate the crash on a stock system.
What do you do, then, if you're a home user with one computer?
On Mon, Mar 16, 2015 at 01:59:17PM -0700, Joe Zeff wrote:
That's a lot of obligation to put onto someone you are not paying. The kernel maintainers have a huge and constantly growing pile of work. I don't think it's unreasonable to ask for bug submitters to recreate the crash on a stock system.
What do you do, then, if you're a home user with one computer?
Reboot into a stock kernel without the modules? Ask other people for help in replicating? Contact the vendor of the binary module and ask for their help?
On 03/16/2015 02:29 PM, Matthew Miller wrote:
Reboot into a stock kernel without the modules? Ask other people for help in replicating? Contact the vendor of the binary module and ask for their help?
My laptop reports several kerneloops every time it boots. AFAIK, there's nothing installed that taints the kernel, but 99% of the time abrt tells me that the kernel is tainted and that I can't report it. Suggestions? (If you need, I can get you a copy of the specifics.)
On Mon, Mar 16, 2015 at 4:25 PM, Joe Zeff joe@zeff.us wrote:
On 03/16/2015 02:29 PM, Matthew Miller wrote:
Reboot into a stock kernel without the modules? Ask other people for help in replicating? Contact the vendor of the binary module and ask for their help?
My laptop reports several kerneloops every time it boots. AFAIK, there's nothing installed that taints the kernel, but 99% of the time abrt tells me that the kernel is tainted and that I can't report it. Suggestions? (If you need, I can get you a copy of the specifics.)
Crude but this should work # journalctl -b -l -o short-monotonic | grep -i "tainted"
That should get you more than one line. What's probably happening is there's an early "Not Tainted" line which is the one to file as a bug. And then any oops that happens after that is always considered tainted because of the first one. If the first oops (for a boot) is tainted, then there's a letter code that indicates why, but Fedora kernels don't ever do this on their own, but if they did that itself would be a bug.
On 03/16/2015 04:43 PM, Chris Murphy wrote:
That should get you more than one line. What's probably happening is there's an early "Not Tainted" line which is the one to file as a bug.
I don't have that for you yet (It's the laptop giving me trouble, and I normally collect my email on my desktop.) but I do have this for you:
Flags:GW
https://retrace.fedoraproject.org/faf/problems/728180/
I don't know what that means, but a pointer in the right direction would be greatly appreciated.
On Sun, Mar 29, 2015 at 7:39 PM, Joe Zeff joe@zeff.us wrote:
On 03/16/2015 04:43 PM, Chris Murphy wrote:
That should get you more than one line. What's probably happening is there's an early "Not Tainted" line which is the one to file as a bug.
I don't have that for you yet (It's the laptop giving me trouble, and I normally collect my email on my desktop.) but I do have this for you:
Flags:GW
https://retrace.fedoraproject.org/faf/problems/728180/
I don't know what that means, but a pointer in the right direction would be greatly appreciated.
You're stubborn. Fortunately, I'm more stubborn. I've asked for a complete dmesg a couple of times and you keep giving snippets, so at this point I really ought to just ignore the requests for help. However...
From your report:
CPU: 0 PID: 871 Comm: Xorg Tainted: G W 3.18.5-101.fc20.i686+PAE #1
https://www.kernel.org/doc/Documentation/oops-tracing.txt 10: 'W' if a warning has previously been issued by the kernel. (Though some warnings may set more specific taint flags.)
So there is a previous warning (or the kernel is very confused). There are a pile of bugs already reported on RHBR and kernel.org about this particular trace you've provided so it seems to be a known problem, likely a regression. But without a complete dmesg there's no way to know whether it's related to any problems you're having.
On 03/29/2015 07:19 PM, Chris Murphy wrote:
So there is a previous warning (or the kernel is very confused). There are a pile of bugs already reported on RHBR and kernel.org about this particular trace you've provided so it seems to be a known problem, likely a regression. But without a complete dmesg there's no way to know whether it's related to any problems you're having.
Next time I fire up the laptop, I'll get a copy of dmesg, put it up on my website and send a link to the list. I didn't do that before simply because I was hoping you wouldn't need to use such a big hammer on the issue.
On 03/17/15 06:25, Joe Zeff wrote:
My laptop reports several kerneloops every time it boots. AFAIK, there's nothing installed that taints the kernel, but 99% of the time abrt tells me that the kernel is tainted and that I can't report it. Suggestions? (If you need, I can get you a copy of the specifics.)
Does "cat /proc/sys/kernel/tainted" return a value? Does "journalctl -r -b | grep -i taint" list a mod?
On 03/16/2015 04:45 PM, Ed Greshko wrote:
On 03/17/15 06:25, Joe Zeff wrote:
My laptop reports several kerneloops every time it boots. AFAIK, there's nothing installed that taints the kernel, but 99% of the time abrt tells me that the kernel is tainted and that I can't report it. Suggestions? (If you need, I can get you a copy of the specifics.)
Does "cat /proc/sys/kernel/tainted" return a value? Does "journalctl -r -b | grep -i taint" list a mod?
I don't know, because I'm at my desktop, not my laptop and don't have time ATM to fire it up and find out. When I do, I'll let you know.
On 03/16/2015 04:45 PM, Ed Greshko wrote:
On 03/17/15 06:25, Joe Zeff wrote:
My laptop reports several kerneloops every time it boots. AFAIK, there's nothing installed that taints the kernel, but 99% of the time abrt tells me that the kernel is tainted and that I can't report it. Suggestions? (If you need, I can get you a copy of the specifics.)
Does "cat /proc/sys/kernel/tainted" return a value?
-bash: cat /proc/sys/kernel/tainted: No such file or directory
Does "journalctl -r -b | grep -i taint" list a mod?
No output at all. Sorry for the delay, but I haven't been using my laptop recently.
On Mon, Mar 16, 2015 at 10:44 AM, jd1008 jd1008@gmail.com wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I think this question needs to go to the Fedora devel@ list, or maybe also kernel@ as a cross-post (explicitly mentioned from the outset it's a crosspost).
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Chris Murphy
On Mon, Mar 16, 2015 at 2:58 PM, Joe Zeff joe@zeff.us wrote:
On 03/16/2015 12:37 PM, Chris Murphy wrote:
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Agreed. That's why I suggested trying to duplicate the crash with an untainted kernel.
Burden is on the user to do this. The distribution provides an untainted kernel. The user chose to use an out of tree module that taints it. It can't be claimed to be a kernel bug when an out of tree module it used, short of the often tedious analysis of exactly how the out of tree kernel affects kernel behavior.
On Mon, Mar 16, 2015 at 3:19 PM, Chris Murphy lists@colorremedies.com wrote:
out of tree kernel affects kernel behavior.
tree kernel ^module
On 03/16/2015 02:58 PM, Joe Zeff wrote:
On 03/16/2015 12:37 PM, Chris Murphy wrote:
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Agreed. That's why I suggested trying to duplicate the crash with an untainted kernel.
Or, abrt should allow the user to submit the bug to some other bugzilla - i.e; not necessarily fedora nor redhat. All abrt needs to do is ask the user for that "other" user's login credentials.
On Tue, Mar 17, 2015 at 2:15 PM, jd1008 jd1008@gmail.com wrote:
On 03/16/2015 02:58 PM, Joe Zeff wrote:
On 03/16/2015 12:37 PM, Chris Murphy wrote:
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Agreed. That's why I suggested trying to duplicate the crash with an untainted kernel.
Or, abrt should allow the user to submit the bug to some other bugzilla - i.e; not necessarily fedora nor redhat. All abrt needs to do is ask the user for that "other" user's login credentials.
a. It actually has to communicate with a server, so whose hosting this "other" bugzilla? b. Then what happens? Who looks at these reports?
Why bother with this infrastructure if no one is going to look at the reports or do anything about them?
On Tue, Mar 17, 2015 at 2:32 PM, Joe Zeff joe@zeff.us wrote:
On 03/17/2015 01:26 PM, Chris Murphy wrote:
Why bother with this infrastructure if no one is going to look at the reports or do anything about them?
Why do you assume that nobody's going to pay attention to those bug reports?
Because they invariably have 8001 other things to do than look at bug reports based on tainted kernels due to kernel modules they know nothing about? And are these even open source modules? If they aren't, then they can't even look at the source code even if they had some desire to become familiar with it.
On 03/17/2015 01:26 PM, Chris Murphy wrote:
On Tue, Mar 17, 2015 at 2:15 PM, jd1008 jd1008@gmail.com wrote:
On 03/16/2015 02:58 PM, Joe Zeff wrote:
On 03/16/2015 12:37 PM, Chris Murphy wrote:
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Agreed. That's why I suggested trying to duplicate the crash with an untainted kernel.
Or, abrt should allow the user to submit the bug to some other bugzilla - i.e; not necessarily fedora nor redhat. All abrt needs to do is ask the user for that "other" user's login credentials.
a. It actually has to communicate with a server, so whose hosting this "other" bugzilla?
I think the point here is that a user could configure ADDITIONAL bugzilla sites. If the kernel aborts and abrt determines it's a tainted kernel, then it could pop up this list of additional sites and let the user report the crash to a site on that list. Yes, this is an extension to abrt, but I think a reasonable (and positive) one.
b. Then what happens? Who looks at these reports?
It rather depends on which site you're reporting to. I think bug reports to companies such as nVidia or AMD or HP or Intel or any one of a number of others would be looked at. I do development work on nVidia CUDA stuff and, while they don't have a bugzilla, they are responsive to bug reports using their other mechanisms.
Why bother with this infrastructure if no one is going to look at the reports or do anything about them?
You're assuming they won't without any reason to think that. The fact they set up a bugzilla in the first place (and the user has login credentials for it) is fairly indicative that they do want to fix problems.
To assume that only the kernel developers or Red Hat (or Suse or Ubuntu or whomever) are the ONLY people that care to fix bugs is rather myopic. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Veni, Vidi, VISA: I came, I saw, I did a little shopping. - ----------------------------------------------------------------------
On 03/17/2015 02:41 PM, Rick Stevens wrote:
On 03/17/2015 01:26 PM, Chris Murphy wrote:
On Tue, Mar 17, 2015 at 2:15 PM, jd1008 jd1008@gmail.com wrote:
On 03/16/2015 02:58 PM, Joe Zeff wrote:
On 03/16/2015 12:37 PM, Chris Murphy wrote:
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Agreed. That's why I suggested trying to duplicate the crash with an untainted kernel.
Or, abrt should allow the user to submit the bug to some other bugzilla - i.e; not necessarily fedora nor redhat. All abrt needs to do is ask the user for that "other" user's login credentials.
a. It actually has to communicate with a server, so whose hosting this "other" bugzilla?
I think the point here is that a user could configure ADDITIONAL bugzilla sites. If the kernel aborts and abrt determines it's a tainted kernel, then it could pop up this list of additional sites and let the user report the crash to a site on that list. Yes, this is an extension to abrt, but I think a reasonable (and positive) one.
b. Then what happens? Who looks at these reports?
It rather depends on which site you're reporting to. I think bug reports to companies such as nVidia or AMD or HP or Intel or any one of a number of others would be looked at. I do development work on nVidia CUDA stuff and, while they don't have a bugzilla, they are responsive to bug reports using their other mechanisms.
Why bother with this infrastructure if no one is going to look at the reports or do anything about them?
You're assuming they won't without any reason to think that. The fact they set up a bugzilla in the first place (and the user has login credentials for it) is fairly indicative that they do want to fix problems.
To assume that only the kernel developers or Red Hat (or Suse or Ubuntu or whomever) are the ONLY people that care to fix bugs is rather myopic.
+1 !!
On Tue, Mar 17, 2015 at 2:41 PM, Rick Stevens ricks@alldigital.com wrote:
On 03/17/2015 01:26 PM, Chris Murphy wrote:
a. It actually has to communicate with a server, so whose hosting this "other" bugzilla?
I think the point here is that a user could configure ADDITIONAL bugzilla sites.
Do you have examples of such additional bugzilla sites?
If the kernel aborts and abrt determines it's a tainted kernel, then it could pop up this list of additional sites and let the user report the crash to a site on that list. Yes, this is an extension to abrt, but I think a reasonable (and positive) one.
If you know the site already, why not just file the bug directly on that bugzilla? Why does it need to be automated?
b. Then what happens? Who looks at these reports?
It rather depends on which site you're reporting to. I think bug reports to companies such as nVidia or AMD or HP or Intel or any one of a number of others would be looked at. I do development work on nVidia CUDA stuff and, while they don't have a bugzilla, they are responsive to bug reports using their other mechanisms.
Why bother with this infrastructure if no one is going to look at the reports or do anything about them?
You're assuming they won't without any reason to think that. The fact they set up a bugzilla in the first place (and the user has login credentials for it) is fairly indicative that they do want to fix problems.
To assume that only the kernel developers or Red Hat (or Suse or Ubuntu or whomever) are the ONLY people that care to fix bugs is rather myopic.
That is true, I was only considering bugs going into the RHBZ. But I don't really see much value in the automated reporting for a kernel oops because the only thing that tends to get reported by abrt with Fedora kernels is dmesg. It's not like you really gain anything by having abrt file it. The OS installer often has something like a dozen files to upload so in that case abrt is nice. But I just don't see the value here unless there were some mechanism to help the user file the bug with the proper BZ. And that's kinda difficult without assuming the out of tree module is actually to blame or incidental to the oops.
The fact of the matter is, you have to understand the call trace and the kernel and probably the module to a fair degree to know what party to send the bug to.
OR, like Matt said several times, test with a stock kernel. Then you know.
On 03/17/2015 02:51 PM, Chris Murphy wrote:
On Tue, Mar 17, 2015 at 2:41 PM, Rick Stevens ricks@alldigital.com wrote:
On 03/17/2015 01:26 PM, Chris Murphy wrote: If the kernel aborts and abrt determines it's a tainted kernel, then it could pop up this list of additional sites and let the user report the crash to a site on that list. Yes, this is an extension to abrt, but I think a reasonable (and positive) one.
If you know the site already, why not just file the bug directly on that bugzilla? Why does it need to be automated?
Because the user is not provided with an easy way to generate the crash report with a full stack dump of all the CPUS, the full contents of RAM and the full kernel binary - so that the dev (who would work on the report) can do a reasonable stack trace. Kernel source is obtainable easily enough, ditto with the source of the "tainting" modules.
Also, how about abrt CREATE the full report, and let the user save it in a file, and submit it to anyone s/he desires? Is THAT too much to ask for???
On Mar 17, 2015 3:30 PM, "jd1008" jd1008@gmail.com wrote:
Because the user is not provided with an easy way to generate the crash report with a full stack dump of all the CPUS, the full contents of RAM and the full kernel binary - so that the dev (who would work on the report) can do a reasonable stack trace.
Abrt doesn't do all that for Fedora kernels as far as I've experienced.
Also, how about abrt CREATE the full report, and let the user save it in a file, and submit it to anyone s/he desires? Is THAT too much to ask for???
I don't know. But it seems like it's the wrong list to ask. And as Fedora is community driven, I'd ask if those third parties would pitch in on the work needed that they'd benefit from, if they value these reports being automated.
Chris Murphy
On Tue, Mar 17, 2015 at 03:29:55PM -0600, jd1008 wrote:
Also, how about abrt CREATE the full report, and let the user save it in a file, and submit it to anyone s/he desires? Is THAT too much to ask for???
Well, you can _ask_ for anything. It is definitely too much to expect someone else to _do_ it if they don't find it interesting (or they're being paid to).
What I can help with is: if you want to _do_ it, and it seems like an overall benefit to Fedora (in the very broad sense), I can help connect you with the right people and I can help remove any obstacles to the work you want to do. For example, in this case, the upstream project is hosted at https://github.com/abrt/abrt/wiki/ABRT-Project. Add the functionality you need, and make a pull request.
On Tue, 2015-03-17 at 14:51 -0600, Chris Murphy wrote:
If you know the site already, why not just file the bug directly on that bugzilla? Why does it need to be automated?
As a general response, I'd say that:
People are more likely to make a bug report if it's not a protracted exercise for them to do so. And, if it's properly automated (actually sends all the required data to be useful), the report might be much more useful than some people would, otherwise, provide.
Having to find the right bugzilla, having to sign up, having to figure out what to report on (which is horrible on an extremely slow website), to look for possible existing bug reports the same as their own, trying to work out if theirs is different or the same. Having to work out how to provide useful debugging information. Making your PC more painful to use by installing debugging packages...
Making manual bugzilla reports has been such a bastard that I'm loath to ever go through it again. Not to mention the experience of a fault being reported, and being ignored. In this (*) case, the fault was observable by everyone, existed across several releases of Fedora, and no effort could be observed into resolving it.
* I reported that if you tried to adjust sound volume with the mouse wheel over a horizontally oriented slider, the sound went down when you scrolled up, and vice versa. As opposed to working in the way that you expected, and how it worked if you were to use the mouse wheel over the top of a vertically oriented slider. That fault sat for YEARS, and I saw no activity on the bug report other than a few other "me toos," and automated responses after a prolonged time (e.g. when new Fedora releases came out) that the matter would be closed if nobody responded saying the fault still existed.
Yes, I'd made reports, before, that had had action taken. But the utter apathy about doing anything on this report, and seeing other people make similar criticisms, just makes one think, "why bother?"
On Tue, Mar 17, 2015 at 8:14 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Tue, 2015-03-17 at 14:51 -0600, Chris Murphy wrote:
If you know the site already, why not just file the bug directly on that bugzilla? Why does it need to be automated?
As a general response, I'd say that:
People are more likely to make a bug report if it's not a protracted exercise for them to do so. And, if it's properly automated (actually sends all the required data to be useful), the report might be much more useful than some people would, otherwise, provide.
I'm not arguing against this. I'm saying in my experience with not tainted kernel problems, ABRT does not file anything except dmesg. So if the idea is that ABRT needs to collect more, there's bigger changes necessary than just pointing ABRT to some other bugzilla.
And that's fine, it's just not going to magically happen by pointing at it though.
I've got a 2.5 year old bug with a working tested patch filed against grubby and there's no movement on it. Not a great example, it's probably an outlier, but nevertheless, getting things done on Fedora is far from automatic. It basically requires first and foremost and advocate, not just someone who points fingers. Next, that advocate builds a relationship with the package maintainer to find out how to get them the things they need to realize a feature. And they might redirect this to upstream but now you have two advocates, which would also include the Fedora packager.
Having to find the right bugzilla, having to sign up, having to figure out what to report on (which is horrible on an extremely slow website), to look for possible existing bug reports the same as their own, trying to work out if theirs is different or the same. Having to work out how to provide useful debugging information. Making your PC more painful to use by installing debugging packages...
Haha ok that's a lot to chew off. In reverse order:
1. Painful to use by installing debug packages - that is a prerequisite to file something more substantial than dmesg.
2. how to provide useful debugging info - if the user will not test a non-tainted kernel I see no possible way for an automated system to know where to file the bug
3. Signing up for multiple bugzillas is basically a given because we live in the f'n Pleistocene where each upstream has their own bug reporters, and Fedora is their downstream. This complaint comes up on devel@ roughly once a year how to get RHBZ to file bugs upstream automagically. Meanwhile upstreams have no universal agreement that they want downstream injecting bug reports into their bug reporter when they haven't been vetted by a human first. *shrug*
Making manual bugzilla reports has been such a bastard that I'm loath to ever go through it again. Not to mention the experience of a fault being reported, and being ignored. In this (*) case, the fault was observable by everyone, existed across several releases of Fedora, and no effort could be observed into resolving it.
If the context is still 3rd party, out of tree kernel modules, this is expected. I'm not saying I approve or that it's ideal. But it's the reality. The bug has to go into the bug reporting system that's accountable for fixing the bug. And the only practical way to know which bug reporting system the oops goes into is to determine if it happens with a not-tainted kernel as well. If the user is unwilling to do this, I don't see a way forward.
- I reported that if you tried to adjust sound volume with the mouse
wheel over a horizontally oriented slider, the sound went down when you scrolled up, and vice versa. As opposed to working in the way that you expected, and how it worked if you were to use the mouse wheel over the top of a vertically oriented slider. That fault sat for YEARS, and I saw no activity on the bug report other than a few other "me toos," and automated responses after a prolonged time (e.g. when new Fedora releases came out) that the matter would be closed if nobody responded saying the fault still existed.
Sounds like a UI bug. Are you talking about tainted kernels (3rd party, out of tree kernel modules)? Or are you talking about something completely different?
Yes, I'd made reports, before, that had had action taken. But the utter apathy about doing anything on this report, and seeing other people make similar criticisms, just makes one think, "why bother?"
Right. Well when enough people throw in the towel, then it's game over, so consider that. There's no chance of fixes if there are no bug reports, even if bug reports don't guarantee fixes. Including pattern information, when a bug does and does not happen, is very important information.
On 03/17/2015 08:22 PM, Chris Murphy wrote:
- how to provide useful debugging info - if the user will not test a
non-tainted kernel I see no possible way for an automated system to know where to file the bug
You are assuming that it's practical (or even possible) to run without a tainted kernel. Most people who use kmod-nvidia do so because they need better graphics than they can get from nouveau. Asking them to do without the OEM drivers (which taint the kernel) may make it difficult if not impossible to get their work done, and it's not always easy. And, in the case of my laptop, I don't even know, as yet, why it's tainted because there's no hardware involved that wasn't installed at the factory. Even if I knew what caused the taint, how am I supposed to remove it? Yes, in theory it should be possible on every computer, but I, at least live in reality, not theory.
On Tue, Mar 17, 2015 at 10:42 PM, Joe Zeff joe@zeff.us wrote:
On 03/17/2015 08:22 PM, Chris Murphy wrote:
- how to provide useful debugging info - if the user will not test a
non-tainted kernel I see no possible way for an automated system to know where to file the bug
You are assuming that it's practical (or even possible) to run without a tainted kernel. Most people who use kmod-nvidia do so because they need better graphics than they can get from nouveau. Asking them to do without the OEM drivers (which taint the kernel) may make it difficult if not impossible to get their work done, and it's not always easy.
I never said it was easy. I'm well aware of the barriers. I'm just reporting the facts. There isn't some magical substitute to figure out oopses.
And, in the case of my laptop, I don't even know, as yet, why it's tainted because there's no hardware involved that wasn't installed at the factory. Even if I knew what caused the taint, how am I supposed to remove it? Yes, in theory it should be possible on every computer, but I, at least live in reality, not theory.
Taint is always caused by out of tree kernel modules. If you haven't installed anything that installs kernel modules, most typically that's video drivers, then it could be an MCE in which case that's a legit Fedora kernel bug to file, but probably also upstream at bugzilla.kernel.org as well.
On 03/17/2015 10:59 PM, Chris Murphy wrote:
Taint is always caused by out of tree kernel modules. If you haven't installed anything that installs kernel modules, most typically that's video drivers, then it could be an MCE in which case that's a legit Fedora kernel bug to file, but probably also upstream at bugzilla.kernel.org as well.
Not in Joe Zeff's case!!!
On Wed, Mar 18, 2015 at 11:18 AM, jd1008 jd1008@gmail.com wrote:
On 03/17/2015 10:59 PM, Chris Murphy wrote:
Taint is always caused by out of tree kernel modules. If you haven't installed anything that installs kernel modules, most typically that's video drivers, then it could be an MCE in which case that's a legit Fedora kernel bug to file, but probably also upstream at bugzilla.kernel.org as well.
Not in Joe Zeff's case!!!
Seeing as there's no dmesg, or lsmod yet available, no one really understands what the cause of the tainted kernel is at all.
On 03/18/2015 06:26 PM, Joe Zeff wrote:
On 03/18/2015 10:18 AM, jd1008 wrote:
Not in Joe Zeff's case!!!
To be more specific, there's nothing like that that I'm aware of. Yet.
Perhaps I misread your message???
On 03/16/2015 04:25 PM, Joe Zeff wrote:
On 03/16/2015 02:29 PM, Matthew Miller wrote:
Reboot into a stock kernel without the modules? Ask other people for help in replicating? Contact the vendor of the binary module and ask for their help?
My laptop reports several kerneloops every time it boots. AFAIK, there's nothing installed that taints the kernel, but 99% of the time abrt tells me that the kernel is taintedand that I can't report it. Suggestions? (If you need, I can get you a copy of the specifics.)
On 03/18/2015 05:34 PM, jd1008 wrote:
On 03/18/2015 06:26 PM, Joe Zeff wrote:
On 03/18/2015 10:18 AM, jd1008 wrote:
Not in Joe Zeff's case!!!
To be more specific, there's nothing like that that I'm aware of. Yet.
Perhaps I misread your message???
I haven't had time to follow the suggestions about finding out what taints the kernel on my laptop. Maybe Saturday.
On 03/18/15 12:42, Joe Zeff wrote:
On 03/17/2015 08:22 PM, Chris Murphy wrote:
- how to provide useful debugging info - if the user will not test a
non-tainted kernel I see no possible way for an automated system to know where to file the bug
You are assuming that it's practical (or even possible) to run without a tainted kernel. Most people who use kmod-nvidia do so because they need better graphics than they can get from nouveau. Asking them to do without the OEM drivers (which taint the kernel) may make it difficult if not impossible to get their work done, and it's not always easy. And, in the case of my laptop, I don't even know, as yet, why it's tainted because there's no hardware involved that wasn't installed at the factory. Even if I knew what caused the taint, how am I supposed to remove it? Yes, in theory it should be possible on every computer, but I, at least live in reality, not theory.
Well, in a previous message you indicated that....
MY kernel is tainted by mods from rpmfusion. yet: $ cat /proc/sys/kernel/tainted 0
So, you're using something from rpmfusion. But you don't know what in particular is causing the tainting.
You could tell the list what rpmfusion sw you've installed as well as showing the output of lsmod for others to see and someone may spot the offending module(s).
FWIW, I believe the the VirtualBox modules will taint but the suggestions I made won't reveal their complicity.
On 03/17/2015 11:09 PM, Ed Greshko wrote:
On 03/18/15 12:42, Joe Zeff wrote:
On 03/17/2015 08:22 PM, Chris Murphy wrote:
- how to provide useful debugging info - if the user will not test a
non-tainted kernel I see no possible way for an automated system to know where to file the bug
You are assuming that it's practical (or even possible) to run without a tainted kernel. Most people who use kmod-nvidia do so because they need better graphics than they can get from nouveau. Asking them to do without the OEM drivers (which taint the kernel) may make it difficult if not impossible to get their work done, and it's not always easy. And, in the case of my laptop, I don't even know, as yet, why it's tainted because there's no hardware involved that wasn't installed at the factory. Even if I knew what caused the taint, how am I supposed to remove it? Yes, in theory it should be possible on every computer, but I, at least live in reality, not theory.
Well, in a previous message you indicated that....
MY kernel is tainted by mods from rpmfusion. yet: $ cat /proc/sys/kernel/tainted 0
So, you're using something from rpmfusion. But you don't know what in particular is causing the tainting.
You could tell the list what rpmfusion sw you've installed as well as showing the output of lsmod for others to see and someone may spot the offending module(s).
FWIW, I believe the the VirtualBox modules will taint but the suggestions I made won't reveal their complicity.
$ lsmod Module Size Used by bnep 19543 2 bluetooth 463099 5 bnep fuse 91371 1 nf_conntrack_ipv4 14656 5 nf_defrag_ipv4 12702 1 nf_conntrack_ipv4 xt_conntrack 12760 5 nf_conntrack 103513 2 xt_conntrack,nf_conntrack_ipv4 uvcvideo 81109 0 videobuf2_vmalloc 13163 1 uvcvideo videobuf2_core 45100 1 uvcvideo videobuf2_memops 13161 1 videobuf2_vmalloc v4l2_common 14543 1 videobuf2_core joydev 17344 0 coretemp 13441 0 videodev 152476 3 uvcvideo,v4l2_common,videobuf2_core iTCO_wdt 13480 0 media 20906 2 uvcvideo,videodev iTCO_vendor_support 13419 1 iTCO_wdt kvm_intel 148304 0 gpio_ich 13579 0 ppdev 17635 0 dell_wmi 12681 0 dell_laptop 14000 0 kvm 471231 1 kvm_intel sparse_keymap 13584 1 dell_wmi dcdbas 14875 1 dell_laptop serio_raw 13434 0 sdhci_pci 23343 0 i2c_i801 18146 0 sdhci 42580 1 sdhci_pci mmc_core 125580 2 sdhci,sdhci_pci arc4 12608 2 iwldvm 245292 0 mac80211 658674 1 iwldvm lpc_ich 21093 0 mfd_core 13182 1 lpc_ich snd_hda_codec_idt 63511 1 snd_hda_codec_generic 67600 1 snd_hda_codec_idt snd_hda_intel 30520 4 snd_hda_controller 30786 1 snd_hda_intel snd_hda_codec 135263 4 snd_hda_codec_idt,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller iwlwifi 129740 1 iwldvm snd_hwdep 17650 1 snd_hda_codec parport_pc 28088 0 parport 40425 2 ppdev,parport_pc snd_seq 70458 0 snd_seq_device 14136 1 snd_seq cfg80211 514867 3 iwlwifi,mac80211,iwldvm snd_pcm 105212 3 snd_hda_codec,snd_hda_intel,snd_hda_controller snd_timer 28778 2 snd_pcm,snd_seq rfkill 21980 5 cfg80211,bluetooth,dell_laptop shpchp 37040 0 snd 80001 17 snd_hwdep,snd_timer,snd_hda_codec_idt,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device soundcore 14496 2 snd,snd_hda_codec tpm_tis 18630 0 tpm 35109 1 tpm_tis acpi_cpufreq 19433 1 nfsd 293485 1 auth_rpcgss 58540 1 nfsd nfs_acl 12741 1 nfsd lockd 92864 1 nfsd grace 13094 2 nfsd,lockd sunrpc 283393 7 nfsd,auth_rpcgss,lockd,nfs_acl binfmt_misc 17424 1 nouveau 1376565 2 mxm_wmi 12865 1 nouveau i2c_algo_bit 13250 1 nouveau drm_kms_helper 93738 1 nouveau ttm 92999 1 nouveau e1000e 238672 0 drm 305543 5 ttm,drm_kms_helper,nouveau uas 22414 2 usb_storage 65065 1 uas ptp 19140 1 e1000e yenta_socket 45128 0 firewire_ohci 44323 0 firewire_core 62559 1 firewire_ohci crc_itu_t 12613 1 firewire_core pps_core 19130 1 ptp wmi 18820 3 dell_wmi,mxm_wmi,nouveau video 19905 1 nouveau
$ yum list installed | grep fusion Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast a52dec-devel.x86_64 0.7.4-19.fc21 @rpmfusion-free akmods.noarch 0.5.1-4.fc21 @rpmfusion-free dvdstyler.x86_64 1:2.8.1-1.fc21 @rpmfusion-free-updates exfat-utils.x86_64 1.1.1-1.fc21 @rpmfusion-free-updates faad2-devel.x86_64 1:2.7-6.fc21 @rpmfusion-free ffmpeg.x86_64 2.4.7-1.fc21 @rpmfusion-free-updates ffmpeg-devel.x86_64 2.4.7-1.fc21 @rpmfusion-free-updates ffmpeg-libs.x86_64 2.4.7-1.fc21 @rpmfusion-free-updates fuse-exfat.x86_64 1.1.0-1.fc21 @rpmfusion-free-updates gnome-mplayer.x86_64 1.0.9-3.20150203svn2476.fc21 @rpmfusion-free-updates gnome-mplayer-common.x86_64 1.0.9-3.20150203svn2476.fc21 @rpmfusion-free-updates gstreamer-plugins-bad.x86_64 0.10.23-6.fc21 @rpmfusion-free gstreamer-plugins-bad-nonfree.x86_64 0.10.23-3.fc21 @rpmfusion-nonfree k3b-extras-freeworld.x86_64 1:2.0.2-21.fc21 @rpmfusion-free kmodtool.noarch 1-23.fc20 @rpmfusion-free libavdevice.x86_64 2.4.7-1.fc21 @rpmfusion-free-updates libdca-devel.x86_64 0.0.5-8.fc21 @rpmfusion-free libdvbpsi-devel.x86_64 1.2.0-1.fc21 @rpmfusion-free libmpeg2-devel.x86_64 0.5.1-11.fc21 @rpmfusion-free libvdpau-va-gl.x86_64 0.3.4-6.fc21 @rpmfusion-free-updates live555-devel.x86_64 2014.10.21-1.fc21 @rpmfusion-free lpf-skype.i686 4.3.0.37-2.fc21 @rpmfusion-nonfree mac-devel.x86_64 3.99-11.u4b5.fc21 @rpmfusion-nonfree mac-libs.x86_64 3.99-11.u4b5.fc21 @rpmfusion-nonfree mate-applet-streamer.x86_64 0.1.3-1.fc21 @rpmfusion-free-updates mencoder.x86_64 1.1-32.20150123svn.fc21 @rpmfusion-free-updates mpg123.x86_64 1.19.0-2.fc21 @rpmfusion-free mplayer.x86_64 1.1-32.20150123svn.fc21 @rpmfusion-free-updates mplayer-common.x86_64 1.1-32.20150123svn.fc21 @rpmfusion-free-updates rpmfusion-free-release.noarch 21-1 installed rpmfusion-nonfree-release.noarch 21-1 installed staging-kmod-addons.noarch 3.18.2-1.fc21 @rpmfusion-free-updates twolame-devel.x86_64 0.3.13-4.fc21 @rpmfusion-free wxsvg.x86_64 1.5.3-1.fc21 @rpmfusion-free-updates @rpmfusion-free-updates<<<<< No package name???? @rpmfusion-free-updates <<<<< No Package name???? x265-devel.x86_64 1.2-6.fc21 @rpmfusion-free-updates x265-libs.x86_64 1.2-6.fc21 @rpmfusion-free-updates xvidcore-devel.x86_64 1.3.2-6.fc21 @rpmfusion-free
I have no idea why there are two lines without a package name!!
On Tue, 2015-03-17 at 21:22 -0600, Chris Murphy wrote:
Sounds like a UI bug.
Agreed. And, it would appear, that becomes a "don't really care about fixing it" issue, as sound still works, even if the controls are backwards.
Are you talking about tainted kernels (3rd party, out of tree kernel modules)? Or are you talking about something completely different?
Standard Fedora install, out of the box.
But I was just using that as an example of an experience with making bug reports.
I just noticed that the fault doesn't appear to exist on this Fedora release (FC20), with the general sound level controls that you get with the MATE desktop (dunno what that actual program is, but it's what you get when you right-click on the taskbar speaker volume control icon, then get the window for sound preferences, then mouse around in it).
Yet the fault still appears with the pulse audio volume controls (which can be brought up by running this command: pavucontrol
On 03/17/2015 02:26 PM, Chris Murphy wrote:
On Tue, Mar 17, 2015 at 2:15 PM, jd1008 jd1008@gmail.com wrote:
On 03/16/2015 02:58 PM, Joe Zeff wrote:
On 03/16/2015 12:37 PM, Chris Murphy wrote:
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Agreed. That's why I suggested trying to duplicate the crash with an untainted kernel.
Or, abrt should allow the user to submit the bug to some other bugzilla - i.e; not necessarily fedora nor redhat. All abrt needs to do is ask the user for that "other" user's login credentials.
a. It actually has to communicate with a server, so whose hosting this "other" bugzilla? b. Then what happens? Who looks at these reports?
Why bother with this infrastructure if no one is going to look at the reports or do anything about them?
They are bugzilla servers, and follow the same protocol of bug submission as the fedora and the redhat report submission protocol. What do YOU care who will bother to look at them, as long as it is not YOU or the fedora devs? Your assumtion there is no one to look at these ooopses and crashes is a very wild one.
On Tue, Mar 17, 2015 at 02:46:15PM -0600, jd1008 wrote:
Why bother with this infrastructure if no one is going to look at the reports or do anything about them?
They are bugzilla servers, and follow the same protocol of bug submission as the fedora and the redhat report submission protocol. What do YOU care who will bother to look at them, as long as it is not YOU or the fedora devs? Your assumtion there is no one to look at these ooopses and crashes is a very wild one.
If you're interested in helping set up this infrastructure and/or reviewing the results, _now_ we're getting somewhere. I don't think there's any fundamental objection to doing so.
On 03/16/2015 01:37 PM, Chris Murphy wrote:
On Mon, Mar 16, 2015 at 10:44 AM, jd1008 jd1008@gmail.com wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I think this question needs to go to the Fedora devel@ list, or maybe also kernel@ as a cross-post (explicitly mentioned from the outset it's a crosspost).
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Chris Murphy
Chris, It does not mean many things. That is not such a good criterion for abrt to reject the submission of the crash.
On Tue, Mar 17, 2015 at 2:11 PM, jd1008 jd1008@gmail.com wrote:
On 03/16/2015 01:37 PM, Chris Murphy wrote:
On Mon, Mar 16, 2015 at 10:44 AM, jd1008 jd1008@gmail.com wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
I think this question needs to go to the Fedora devel@ list, or maybe also kernel@ as a cross-post (explicitly mentioned from the outset it's a crosspost).
Just because the crash doesn't occur in an out of tree module, doesn't mean that the out of tree module isn't instigating the problem though.
Chris Murphy
Chris, It does not mean many things. That is not such a good criterion for abrt to reject the submission of the crash.
I think it's a good criterion. You don't. Others have stated practical technical reasons they shouldn't go in the reporting system, and you just discard them out of hand. You want what you want because you want it is perhaps understandable, but it's not going to change minds or win arguments.
On Mon, Mar 16, 2015 at 10:44:16AM -0600, jd1008 wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
Kernel modules can pretty much do whatever they like once they're loaded; how do you demonstrate that the crash in some other area is not actually caused by the binary module you loaded?
On 03/16/2015 02:43 PM, Matthew Miller wrote:
On Mon, Mar 16, 2015 at 10:44:16AM -0600, jd1008 wrote:
Since none of the crashes occur in the modules inserted via akmods, why is the fedora abrt not allowing thes ending of such reports?
Kernel modules can pretty much do whatever they like once they're loaded; how do you demonstrate that the crash in some other area is not actually caused by the binary module you loaded?
Again, this is not a good nor sufficient criterion for preventing the submission of the crash.
-
Chris Murphy -
Ed Greshko -
JD -
Joe Zeff -
Matthew Miller -
Rick Stevens -
Roger Heflin -
Tim