On 11/25/2009 11:13 PM, Neil Brown wrote: > On Wed, 25 Nov 2009 21:22:57 +0100 > Jiri Slaby <jirislaby@xxxxxxxxx> wrote: > >> It doesn't make sense at all. How can empty merge cause a regression? >> And md/for-next doesn't produce the BUG. > > I've hit that situation before. Two separate changes in separate > branches conspire to cause a problem. > > md/for-next contains code to handle barriers properly for all levels, > not just RAID1. > It is possible I got this wrong in some way, and some new sanity check > in a separate branch is firing, or it is possible some other bug in > barrier handling has been added and now that MD sends barriers, it is > being triggered. > > What I did to find the actual offending patches is to got to one of the > heads just before the merge, and cherry-pick all the patches from the > other branch, and then bisect that. > cherry-pick is hard work. Stand on the merge point and do: git rebase -i HEAD^ That will cherry-pick all these for you in one easy command ;-) Boaz > NeilBrown > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
