Crashes of tainted kernels

[JD]

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.

[Joe Zeff]

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.

[Joe Zeff]

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.

[Chris Murphy]

On Sun, Mar 29, 2015 at 7:39 PM, Joe Zeff <joe(a)zeff.us&gt; 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.



-- 
Chris Murphy

[Joe Zeff]

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.

[Joe Zeff]

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.

[JD]

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.)

[Joe Zeff]

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.

[Chris Murphy]

On Wed, Mar 18, 2015 at 11:18 AM, jd1008 <jd1008(a)gmail.com&gt; 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.

-- 
Chris Murphy

[JD]

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!!!

[JD]

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:
> >> 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
> > 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!!

[Chris Murphy]

On Tue, Mar 17, 2015 at 8:14 PM, Tim <ignored_mailbox(a)yahoo.com.au&gt; 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.


-- 
Chris Murphy

[JD]

On 03/16/2015 05:45 PM, Ed Greshko wrote:
>  cat /proc/sys/kernel/tainted 
Ed, even that is no help.
MY kernel is tainted by mods from rpmfusion. yet:
$ cat /proc/sys/kernel/tainted
0

So, what does that leave the user?
abrt says it is tainted, which is correct.

[Ed Greshko]

On 03/17/15 07:43, Chris Murphy wrote:
>  Crude but this should work
>  # journalctl -b -l -o short-monotonic | grep -i "tainted" 
That won't work since the string in the journal is "taints kernel"

-- 
If you can't laugh at yourself, others will gladly oblige.

[Joe Zeff]

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.

[Matthew Miller]

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Chris Murphy]

On Mar 17, 2015 3:30 PM, "jd1008" <jd1008(a)gmail.com&gt; 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

[Ed Greshko]

On 03/18/15 12:42, Joe Zeff wrote:
>  On 03/17/2015 08:22 PM, Chris Murphy wrote:
> > 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
>
>  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.

-- 
If you can't laugh at yourself, others will gladly oblige.

[Chris Murphy]

On Tue, Mar 17, 2015 at 10:42 PM, Joe Zeff <joe(a)zeff.us&gt; wrote:
>  On 03/17/2015 08:22 PM, Chris Murphy wrote:
> >
> > 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
>
>
>  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.


-- 
Chris Murphy

[Tim]

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

-- 
tim@localhost ~]$ uname -rsvp

Linux 3.18.7-100.fc20.i686 #1 SMP Wed Feb 11 21:16:53 UTC 2015 i686

All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.

George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.

[Joe Zeff]

On 03/17/2015 08:22 PM, Chris Murphy wrote:
>  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 
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.

[Tim]

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?"

-- 
tim@localhost ~]$ uname -rsvp

Linux 3.18.7-100.fc20.i686 #1 SMP Wed Feb 11 21:16:53 UTC 2015 i686

All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.

George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.

[Matthew Miller]

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[JD]

On 03/17/2015 02:51 PM, Chris Murphy wrote:
>  On Tue, Mar 17, 2015 at 2:41 PM, Rick Stevens
> <ricks(a)alldigital.com&gt; 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???

[Chris Murphy]

On Tue, Mar 17, 2015 at 2:41 PM, Rick Stevens <ricks(a)alldigital.com&gt; 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.


-- 
Chris Murphy

[JD]

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(a)gmail.com&gt; 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 !!

[JD]

On 03/17/2015 02:26 PM, Chris Murphy wrote:
>  On Tue, Mar 17, 2015 at 2:15 PM, jd1008 <jd1008(a)gmail.com&gt;
> 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.

[Rick Stevens]

On 03/17/2015 01:26 PM, Chris Murphy wrote:
>  On Tue, Mar 17, 2015 at 2:15 PM, jd1008 <jd1008(a)gmail.com&gt;
> 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(a)alldigital.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-     Veni, Vidi, VISA:  I came, I saw, I did a little shopping.     -
----------------------------------------------------------------------

[Chris Murphy]

On Tue, Mar 17, 2015 at 2:32 PM, Joe Zeff <joe(a)zeff.us&gt; 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.

-- 
Chris Murphy

[Joe Zeff]

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?

[Chris Murphy]

On Tue, Mar 17, 2015 at 2:15 PM, jd1008 <jd1008(a)gmail.com&gt; 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?


-- 
Chris Murphy

[Chris Murphy]

On Tue, Mar 17, 2015 at 2:11 PM, jd1008 <jd1008(a)gmail.com&gt; wrote:
>  On 03/16/2015 01:37 PM, Chris Murphy wrote:
> >
> > On Mon, Mar 16, 2015 at 10:44 AM, jd1008 <jd1008(a)gmail.com&gt; 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.


-- 
Chris Murphy

[JD]

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.

[JD]

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.

[JD]

On 03/16/2015 01:37 PM, Chris Murphy wrote:
>  On Mon, Mar 16, 2015 at 10:44 AM, jd1008 <jd1008(a)gmail.com&gt;
> 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.

[Joe Zeff]

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.

[Ed Greshko]

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?

-- 
If you can't laugh at yourself, others will gladly oblige.

[Chris Murphy]

On Mon, Mar 16, 2015 at 4:25 PM, Joe Zeff <joe(a)zeff.us&gt; 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.

-- 
Chris Murphy

[Joe Zeff]

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.)

[Matthew Miller]

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?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Chris Murphy]

On Mon, Mar 16, 2015 at 3:19 PM, Chris Murphy <lists(a)colorremedies.com&gt; wrote:

>  out of tree kernel affects kernel behavior. 
tree kernel ^module



-- 
Chris Murphy

[Chris Murphy]

On Mon, Mar 16, 2015 at 2:58 PM, Joe Zeff <joe(a)zeff.us&gt; 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.

-- 
Chris Murphy

[Joe Zeff]

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?

[Matthew Miller]

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.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

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?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Chris Murphy]

On Mon, Mar 16, 2015 at 10:44 AM, jd1008 <jd1008(a)gmail.com&gt; 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

[Roger Heflin]

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(a)gmail.com&gt; 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(a)zeff.us&gt; 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(a)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(a)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

[JD]

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(a)zeff.us&gt; 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(a)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.

[JD]

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.

[Roger Heflin]

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(a)zeff.us&gt; 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(a)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

[Joe Zeff]

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.