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@xxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxxxxxxxxxx > 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx 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
