On Mon, 6 Dec 2010 09:59:11 +0200 (EET) Kai Makisara <Kai.Makisara@xxxxxxxxxxx> wrote: > On Thu, 2 Dec 2010, Kai Makisara wrote: > > > On Wed, 1 Dec 2010, Lukas Kolbe wrote: > > > > > Am Dienstag, den 30.11.2010, 18:20 +0200 schrieb Kai Makisara: > > > > > ... > > > > If you see error with 64 kB block size, I would like to see any messages > > > > associated with these errors. > > > > > > I have now hit this bug again. Trying to read and write a label from the > > > tape drive in question results in this (via bacula's btape command): > > > > ... > > > [158529.011206] st1: Can't allocate 2097152 byte tape buffer. > > > [158544.348411] st: append_to_buffer offset overflow. > > > [158544.348416] st: append_to_buffer offset overflow. > > > [158544.348418] st: append_to_buffer offset overflow. > > > [158544.348419] st: append_to_buffer offset overflow. > > > > > The messages except the first one are something that should never happen. > > I think that there is something wrong with returning from enlarge_buffer() > > when it fails. I will look at this when I have time. > > > OK, today I have had some time (national holiday). I think I have tracked > down this problem. The patch at the end should fix it. Basically, > normalize_buffer() needs to know the order of the pages in order to > properly free the pages and update the buffer size. When allocation > failed, the order was not yet stored into the tape buffer definition. This > does explain the problem after allocation failed. Ah, nice catch! I've not tested the patch but looks correct. > Why allocation failed is > another problem which has been discussed elsewhere. Yeah. Thanks a lot! -- 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
