David Gümbel wrote: > > Aug 21 15:30:09 [kernel] EXT3-fs error (device loop0): ext3_readdir: > > directory # 802557 contains a hole at offset 348160 > > Aug 21 15:30:09 [kernel] ext3_abort called. > > Aug 21 15:30:09 [kernel] EXT3-fs error (device loop0) in > > start_transaction: Jour > > nal has aborted > > - Last output repeated 3 times - > > So the problem doesn't seem to be related to register parameters. > > Any ideas? Even though I have been unable to reproduce these errors, I believe I found the cause of these errors. Kernel 2.6.7 to 2.6.8.1 change involved block driver API change which is rather nasty thing to do in "stable" kernel series. When file system code (or in this case loop code) sends I/O requests to block driver, it fills up a struct bio that tells driver what it should do. In this case two new entries were added to struct bio, and 2.6 loop code didn't initialize those value to sane default values that I/O elevator code was expecting. IOW, elevator code was accessing a structure that had two uninitialized variables. Does the patch below fix the problem? David, if you ack that this patch fixes it for you, then I will have to make new version of loop-AES ASAP. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD --- loop-AES-v2.1c/loop.c-2.6.patched.old Fri Jul 23 19:30:26 2004 +++ loop-AES-v2.1c/loop.c-2.6.patched Sun Aug 22 18:25:36 2004 @@ -508,6 +508,10 @@ bio->bi_phys_segments = 0; bio->bi_hw_segments = 0; bio->bi_size = len = orig_bio->bi_io_vec[merge->bi_idx].bv_len; +#if defined(BIOVEC_VIRT_START_SIZE) + bio->bi_hw_front_size = 0; + bio->bi_hw_back_size = 0; +#endif /* bio->bi_max_vecs not touched */ bio->bi_io_vec[0].bv_len = len; bio->bi_io_vec[0].bv_offset = 0; - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/