Mike Christie wrote: > Mike Christie wrote: >> James Bottomley wrote: >>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: >>>>> I can't even say if the tapes are written correctly as I can't read them >>>>> (one does not reboot production machines back to 2.4.x just to try to >>>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on these >>>>> machines). >>>> Could you try this patch >>>> http://marc.info/?l=linux-scsi&m=116464965414878&w=2 >>>> I thought st was modified to not send offsets in the last elements but >>>> it looks like it wasn't. >>> Actually, there are two patches in the email referred to. If the >>> analysis that we're passing NULL to mempool_free is correct, it should >>> be the second one that fixes the problem (the one that checks >>> bio->bi_io_vec before freeing it). Which would mean we have a >>> nr_vecs==0 bio generated by the tar somehow. >>> >> I think we might only need the first patch if the problem is similar to >> what the lsi guys were seeing. I thought the problem is that we are not >> estimating how large the transfer is correctly because we do not take >> into account offsets at the end. This results in nr_vecs being zero when >> it should be a valid value. I thought Kai's patch: >> http://bugzilla.kernel.org/show_bug.cgi?id=7919 >> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104 >> fixed the problem on st's side, > > Oh, I noticed that the subject for the mail references 2.6.30.3 and the > patch for st in the bugzilla did not make into 2.6.20 and is not in .3. > Could we try the st patch in the bugzilla first? Ok, the st patch from bugzilla solves the problem (tested on both affected machines). -- Andreas Steinmetz SPAMmers use robotrap@xxxxxxxx - 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
