--- On Mon, 2/4/08, Tony Battersby <tonyb@xxxxxxxxxxxxxxx> wrote: > I _really_ _really_ hope that you don't believe that I > am trying to take > credit for your work. If you take another look, my original > patch had > the following hunk: > > + > + /* Make sure that bad_lba is one of the sectors that the > + * command was trying to access. > + */ > + if (bad_lba < start_lba || > + bad_lba >= start_lba + xfer_size / sector_size) > + goto out; > + > > > Your response patch had the following hunk: > > + if (bad_lba < start_lba) > + goto out; > > > So I don't feel that it was dishonest for me to submit > this as "my" > work. If you were offended, then I apologize. Oh, no, of course not. The most important thing is if it works for you and fixes your problem and makes your customers happy (or you if you're a customer). > > I think it would've been much clearer if you had > > singled out the problems you were seeing with your > > HW and sent a single problem with a single patch per > > single email. > > > > > Agreed. Sometimes it is difficult to predict when something > that seems > so straightforward will generate so much controversy. Nah, maybe a couple of misunderstandings (email tends to do that), but it's all good. I think it would've been so much better for everyone if the RAID vendor had simply fixed their code to not set VALID when INFORMATION is not valid (spec behaviour). Since the bug lies in their code, that would've been the proper course of action. Instead, every other OS which uses that RAID HW would have to adjust to this RAID FW bug (if they haven't already). Oh, well. Luben - 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
