On 05/26/2015 12:32 PM, Josh Boyer wrote:
On Fri, May 22, 2015 at 7:49 PM, Jakub Filak <jfi...@redhat.com> wrote:
Hi Laura,
Thank you for the patch.
The implementation seems OK to me, but I am not sure if the logic is OK.
Perhaps someone more experienced in triaging kernel bugs can verify the
component transitions.
The transitions are pretty simple:
Anything with 'i915' in the oops backtrace goes to xorg-x11-drv-intel
Anything with 'nouveau' in the oops backtrace goes to xorg-x11-drv-nouveau
Anything with 'radeon' in the oops backtrace goes to xorg-x11-drv-ati
(unfortunate name mismatch).
Anything with 'qxl' in the oops backtrace goes to xorg-x11-drv-qxl
For oopses with "drm_" in the functions but no clearly identified
driver in the oops, one of two things can be done there. Either the
driver can be parsed from the list of loaded modules, or we could
simply leave bugs like this assigned to the kernel for now.
I currently have drm just getting funneled to Intel. I'll just let it
keep being assigned to kernel for now. Backtraces that have just drm
and no other tagged modules are probably worth taking the time to
look at.
These rules do have a small possibility of false-positives, but the
vast majority of kernel DRM bugs would be immediately assigned to the
proper component. I think the patch accomplishes most of this, but
not all of it. One other item we probably want is add kernel-maint on
CC for bugs that get filed via ABRT in this way.
The bugzilla filing is a separate project, libreport. Would it be
acceptable to create another file in the dump directory with a list
of ccs to be added by libreport?
josh
Anyway, could you please add a pair of examples to the examples/ directory
and add the examples to the following tests:
tests/runtests/oops-processing/runtest.sh
tests/runtests/journal-oops-processing/runtest.sh
Yes, I had a couple of dmesg I used for testing. I'll add them to the
examples.
Thanks,
Laura
