Bug 7698 – unable to use loop devices after gcc upgrade

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Charles Mauch 2002-09-09 13:10:57 UTC]

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

[Comment 1 SpanKY 2002-09-09 13:43:07 UTC]

did you try recompiling all the related programs ?

i.e. recompile your kernel and the mount tools and such

[Comment 2 Charles Mauch 2002-09-09 14:31:22 UTC]

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.

[Comment 3 Charles Mauch 2002-09-10 12:32:37 UTC]

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.

[Comment 4 Charles Mauch 2002-09-13 18:39:49 UTC]

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.

[Comment 5 Michael Cohen (RETIRED) 2002-09-25 08:29:17 UTC]

we aren't updating crypto-sources, or at least we haven't been.  use
gentoo-sources 2.4.19-r9.  =)