Re: Automatic Kernel Bug Report

[Diego Calleja]

El Sun, 9 Jul 2006 16:37:46 -0400,
"Daniel Bonekeeper" <thehazard@xxxxxxxxx> escribió:


> preempt tasks. If we can keep track of the timestamp of the last time
> the schedule ran, and we see that it was like 5 or 10 seconds ago, it
> means that something is very wrong on the kernel side. We may have
> several levels of fucked-up-ness in which, at a certain level,
> interrupts are still called (and we can call our code here to check
> the sanity of the system). If we see that we didn't schedule for a
> long time, we can trigger the report system (then again, ideally we

That's what NMIs are for

Note that while I like the idea of automatically reporting such bugs
I fully agree with Adrian that it's not a critical issue right now.
It's not that kernel developers are sleeping while users hit tons
of bugs that won't get reported, right now we've _too many_ bug 
reports and developers are not fixing/noticing them as fast as they
get reported. Take a look at kernel.org's bugzilla, and at the kernel
component of fedora/ubuntu/debian/gentoo bugzillas. We're not 
lacking bug reports, quite the contrary: We're getting so many
that some people is starting to question (again) if the current
development model is the right one and whether we should make
a bug-fix-only release.

In fact, one of the main problems is that there's not an "official"
bug reporting tool beyond email. Many kernel developers didn't
like bugzilla when it was started, and as for today, many core 
kernel developers still do not even _look_ at bugzilla.kernel.org.
The hard work of akpm and some cool people like the acpi guys has
made possible lately to start using bugzilla as a sort of
"official" bugzilla, but there're still many kernel developers
that need to be convinced (and many bugzilla features that need
to be polished). AFAIK, people is going to talk seriusly about 
this in OLS.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/