I recently upgraded and recompiled my system to gcc 3.2 and the new glib. Since upgrading, I've been unable to either access loop devices or mount loop disks. Symptoms: When I attempt to mount a loopback file or partition, the mount process hangs and the following data is dumped into my kern.log. This problem persists even after removing all gcc 3.2 optimzations and recompiling the kernel, and util-linux (package that contains losetup, mount, etc) without those optimizations. This also happens when attempting to use losetup to attach or detatch a loop device to a file. The rest of the system seems to run fine - and I've seen no other (major) problems with the upgrade to gcc 3.2 and compiling the rest of my system against it. Sep 6 20:06:45 terminus general protection fault: 0000 Sep 6 20:06:45 terminus CPU: 0 Sep 6 20:06:45 terminus EIP: 0010:[<c0123955>] Tainted: P Sep 6 20:06:45 terminus EFLAGS: 00010086 Sep 6 20:06:45 terminus eax: c1347204 ebx: c8a78000 ecx: 00000003 edx: ffffffff Sep 6 20:06:45 terminus esi: cfa703d8 edi: cfa703d8 ebp: 00000400 esp: c8a79f30 Sep 6 20:06:45 terminus ds: 0018 es: 0018 ss: 0018 Sep 6 20:06:45 terminus Process mounloop3 (pid: 27519, stackpage=c8a79000) Sep 6 20:06:45 terminus Stack: c8a79f40 d1107b42 c8a7823e c8a78000 d1107b60 c8a78588 00000f00 c7b93f1c Sep 6 20:06:45 terminus cfa703d8 00000400 0000000f 00000000 0034003d 00000011 00000011 00000000 Sep 6 20:06:45 terminus 0034003d 00000000 00000000 00000000 cfa704fc cfa70500 cfa70504 00000000 Sep 6 20:06:45 terminus Call Trace: [<d1107b42>] [<d1107b60>] [<c0107325>] [<c010732e>] [<d1107a30>] Sep 6 20:06:45 terminus Sep 6 20:06:45 terminus Code: 8b 1a 89 54 24 04 89 04 24 e8 7d fc 00 00 ff 0d a4 0c 34 c0 :: System configuration $ uname -a Linux terminus 2.4.19-crypto-r7 #10 Sat Sep 7 10:07:54 PDT 2002 i686 GenuineIntel $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 651.516 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1286.14 $ mount --version mount: mount-2.11u
did you try recompiling all the related programs ? i.e. recompile your kernel and the mount tools and such
yes - i've compled the kernel, the util-linux package, as well as the binutils package in various ways - with various optimizations and without any. Same result.
This problem does not exist in the kernel-2.4.19-gentoo-r9 sources. It looks like the crypto-api is slightly newer in these sources, and this bug was stomped in it. Maybe someone ought to backport the new crypto-api into the crypto-sources? The only other reason i can think of that may have fixed this is that in the gentoo-r9 sources, it's been optimized for gcc 3.1.
Just for giggles, I installed a vanilla kernel and patched with as many as the patches I could find listed for inclusion in the crypt-sources. When I used the older crypto-api, this problem manifested itself again. The newer crypto-api seems to fix this problem. In short, this bug is definately fixable by upgrading to a newer version of the crypto-api.
we aren't updating crypto-sources, or at least we haven't been. use gentoo-sources 2.4.19-r9. =)