http://bugzilla.kernel.org/show_bug.cgi?id=5700
I reported this bug a while back, but it hasn't received any feedback.
Jeff Garzik didn't respond to the email that I sent to him either. What's up?
- Tronic -
On Sat, 2006-01-28 at 13:56 +0200, Lasse Kärkkäinen / Tronic wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=5700
>
> I reported this bug a while back, but it hasn't received any feedback.
> Jeff Garzik didn't respond to the email that I sent to him either. What's up?
While not responding to mails is not nice, demanding a response isn't
nice either. Jeff Garzik or any other kernel developer has no support
obligation to you in any way or form.
Maybe think about if there's more information you can supply to make it
easier for the developers to diagnose (this is the most common reason
bugs aren't looked at, just plain not enough info to even begin thinking
about it)... or look at the code yourself, or try to find where this
behavior started, or .. or ...
On 1/28/06, Arjan van de Ven <[email protected]> wrote:
> Maybe think about if there's more information you can supply to make it
> easier for the developers to diagnose (this is the most common reason
> bugs aren't looked at, just plain not enough info to even begin thinking
> about it)... or look at the code yourself, or try to find where this
> behavior started, or .. or ...
The simplest thing you can do on your own is to see if you can find an
older kernel that doesn't have that problem. And if you do find a
working kernel, you can use git bisect to find out the exact changeset
that broke it. See the following URL for details:
http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt
Pekka
On Sat, Jan 28, 2006 at 01:56:21PM +0200, Lasse K??rkk??inen / Tronic wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=5700
>
> I reported this bug a while back, but it hasn't received any feedback.
> Jeff Garzik didn't respond to the email that I sent to him either. What's up?
>
Hello, Lasse.
Can you please apply the following patch and report the result? It
seems that your drive/controller times once in a while and the timed
out command gets completed twice somehow. The following patch will
show us what's completing it the second time. Also, posting full
kernel log will be helpful too. Among other things, I'm curious
whether there were any recovered timeouts before.
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 41ea7db..28f247a 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -68,6 +68,7 @@
if(unlikely(!(expr))) { \
printk(KERN_ERR "Assertion failed! %s,%s,%s,line=%d\n", \
#expr,__FILE__,__FUNCTION__,__LINE__); \
+ dump_stack(); \
}
#endif