Subject: Re: [BUG] New Kernel Bugs
From: Romano Giannetti <romanol@upcomillas.es>
To: Adrian Bunk <bunk@kernel.org>
Cc: Ray Lee <ray-lk@madrabbit.org>, "Giacomo A. Catenazzi" <cate@cateee.net>,
       Mark Lord <liml@rtr.ca>, Ingo Molnar <mingo@elte.hu>,
       Andrew Morton <akpm@linux-foundation.org>,
       David Miller <davem@davemloft.net>, protasnb@gmail.com,
       linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
       alsa-devel@alsa-project.org, linux-ide@vger.kernel.org,
       linux-pcmcia@lists.infradead.org, linux-input@atrey.karlin.mff.cuni.cz,
       bugme-daemon@bugzilla.kernel.org
In-Reply-To: <20071113170141.GD4250@stusta.de>
References: <20071113031553.3c7b5c16.akpm@linux-foundation.org>
	 <20071113.033946.114918709.davem@davemloft.net>
	 <20071113034916.2556edd7.akpm@linux-foundation.org>
	 <20071113.035824.40509981.davem@davemloft.net>
	 <20071113041259.79c9a8c5.akpm@linux-foundation.org>
	 <20071113134029.GA30978@elte.hu> <4739AFE0.20705@rtr.ca>
	 <4739C1B0.8000803@cateee.net>
	 <2c0942db0711130757g295add20re0ee423b84921d28@mail.gmail.com>
	 <20071113170141.GD4250@stusta.de>
Content-Type: text/plain; charset=ISO-8859-1
Date: Tue, 13 Nov 2007 18:50:38 +0100
Message-Id: <1194976238.15745.17.camel@rukbat>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3204
Lines: 69


I jump in this discussion hoping to have some more insight on git and to
report my experience as a tester. I consider myself as half-literate in
this (I am here since 1991, more or less, and I am able to compile a
kernel and even hand-apply a patch, although I am in no way a kernel
programmer). 

On Tue, 2007-11-13 at 18:01 +0100, Adrian Bunk wrote:

> The small instruction below is enough for everyone who is able to 
> build his own kernel to do a git bisect.

> # start bisecting:
> cd linux-2.6
> git bisect start
> git bisect bad v2.6.21
> git bisect good v2.6.20
> cp /path/to/.config .
> 

This was what I did in my (in the end almost successful) bisecting when
trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my
SD card"). This is true in theory, but it has some problem. The "this
commit does not compile is the easiest and in man git-bisect it's
explained how to solve it. The changes in .config options, added or
removed, are another problem when jumping back and forth from version (I
was bitten by the gadzillions new options added to hda-intel alsa
driver, but well, that is solvable with a bit of attention).

The main problem I had, and that stopped me to arrive to a definite is
this situation:

j version-bad
i
h
g unrelated (but similar) bug corrected
f
e
d unrelated (but similar) bug introduced
c
b
a version-good 

(d was the series to change drivers to use sg helpers, and g was a "fix
fallout from sg helpers" patch). Now I have a series of kernels (d, e,
f) that did not work at all and so I cannot mark them good or bad. With
the number of patches added in the free-for-all week, this is a very
probable scenario. There is a way out from this using bisect?

Romano 

PS as a suggestion, I think that added a "Reported-by", or "Tested-by",
or "Debugged-by" attribution in the repository, as happened to be in the
MMC case, is a nice an d welcomed reward for the effort.    

-- 
Sorry for the disclaimer --- ?I cannot stop it!


--
La presente comunicaci?n tiene car?cter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribuci?n, reproducci?n o uso de esta comunicaci?n y/o de la informaci?n contenida en la misma est?n estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicaci?n por error, por favor, notif?quelo inmediatamente al remitente contestando a este mensaje y proceda a continuaci?n a destruirlo. Gracias por su colaboraci?n.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/