[lkml]   [2006]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Automatic Kernel Bug Report
    > I'm sorry for being so negative, but it seems you are overdesigning a
    > solution for a non-existing problem:
    > There are cases where the machine is simply dead with exactly zero
    > information. These are the really hard ones.

    Then really there isn't anything that we can do, except to expect the
    kindness of the user in taking a picture of his screen and posting on
    the kernel's bugzilla.

    > Then there are cases where the kernel is able to print a BUG() or Oops
    > to a log file. Or the error message is printed to the screen and the
    > user uses a digital camera and sends the photo.

    Then again, users may just continue using the machine (without even
    noticing the Oops), or notice but never care to report it, or forgets,

    > The message is usually enough for starting to debug the problem or
    > asking the user for additional information.
    > But most important, the problem lies in a completely different area:
    > Interaction between kernel devlopers and users is not a real problem.
    > The real problem is the missing developer manpower for handling bug
    > reports.

    Well Adrian, this is the other side of the problem. We don't actually
    need a kernel monkey to keep looking for bugs that comes (even thought
    would be good, but as you stated, there is not enough manpower to do
    that), even more after having something that automatically sends Oops
    reports to the server, where we could expect thousands of bug reports
    daily... but I also believe that not having somebody to look at them
    is not an excuse for not having this bug taken account for. For
    example, even though we may not debug each and every bug report, we
    can have statistics for which modules are reporting more problems (and
    therefore, have more bugs). For example, I don't really expect
    Microsoft to investigate every crash report that users send, but it is
    definitely important to have bugs accounted for. Let's say that the
    SCSI maintainer just did a big change to the SCSI subsystem and wants
    to know how is it going: he just goes to bugzilla and see statistics
    about increase of the ratio of bug reports compared to the last
    version, or he can also see which functions (based on the EIP as a
    guess) are reporting more problems.

    In resume, don't being able to investigate each report isn't a reason
    for not being acknowledged of its existance, and even we don't
    investigate it, having it for statistical purposes is already a great


    What this world needs is a good five-dollar plasma weapon.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-07-09 20:49    [W:0.024 / U:18.848 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site