In article <[email protected]>,
Florian Weimer <[email protected]> wrote:
| Soeren Sonnenburg wrote:
|
| > losetup -e blowfish /dev/loop0 /file
| > Password:
| > mkfs -t ext3 /dev/loop0
| > mount /dev/loop0 /mnt
| > <error unknown fs type>
| > <from here something was seriously broken... could not reboot anymore>
|
| I'm seeing something similar, but in my case, mke2fs already crashes.
|
| > system is:
| > Linux no 2.6.0-test7 #8 Sun Oct 26 17:00:49 CET 2003 ppc GNU/Linux
|
| Mine ist -test9 on x86.
|
| Have you found a solution in the meantime?
I have been using aes and not seeing this. I suppose it's unlikely that
there could be an error in the kernel crypto, but I think I'll wait and
try blowfish on a non-critical machine.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
At 09:41 11/11/2003, you wrote:
>In article <[email protected]>,
>Florian Weimer <[email protected]> wrote:
>| Soeren Sonnenburg wrote:
>|
>| > losetup -e blowfish /dev/loop0 /file
>| > Password:
>| > mkfs -t ext3 /dev/loop0
>| > mount /dev/loop0 /mnt
>| > <error unknown fs type>
>| > <from here something was seriously broken... could not reboot anymore>
>|
>| I'm seeing something similar, but in my case, mke2fs already crashes.
>|
>| > system is:
>| > Linux no 2.6.0-test7 #8 Sun Oct 26 17:00:49 CET 2003 ppc GNU/Linux
>|
>| Mine ist -test9 on x86.
>|
>| Have you found a solution in the meantime?
>
>I have been using aes and not seeing this. I suppose it's unlikely that
>there could be an error in the kernel crypto, but I think I'll wait and
>try blowfish on a non-critical machine.
My solution has been to not use cryptofs, it crashes with whatever
algorithm I choose :-(
I agree that something is very broken, though. Mind you, I can only
replicate this problem on one of my machines - the other one I've tried it
on seems to work fine. Odder still, when I compile a kernel on the machine
which is fine and ruin said kernel on the machine which is not fine, I
don't experience the crash.
I've attached a traced session plus the config used, may it be of use to
someone (please! :-)
- Peter.
On Tue, 11 Nov 2003, Peter Lieverdink wrote:
>
> I agree that something is very broken, though. Mind you, I can only
> replicate this problem on one of my machines - the other one I've tried it
> on seems to work fine. Odder still, when I compile a kernel on the machine
> which is fine and ruin said kernel on the machine which is not fine, I
> don't experience the crash.
That _really_ sounds like your "broken machine" is nothing more than a
broken compiler (or possibly binutils, but compilers tend to be more
fragile by far, so it's more likely the compiler).
What compiler versions do you have installed on the broken vs good
machines?
Linus
On Tue, 11 Nov 2003 10:27:16 +1100, Peter Lieverdink <[email protected]> said:
> I agree that something is very broken, though. Mind you, I can only
> replicate this problem on one of my machines - the other one I've tried it
> on seems to work fine. Odder still, when I compile a kernel on the machine
> which is fine and ruin said kernel on the machine which is not fine, I
> don't experience the crash.
Could we see a 'gcc -V' from *both* machines, please? (and an 'as -v'
and 'ld -v' as well, just to be thorough?)
Linus Torvalds wrote:
> What compiler versions do you have installed on the broken vs good
> machines?
GCC 3.3.2 (Debian 3.3.2-3) is broken for me (binutils is 2.14.89.0.7-2).
Which compiler is recommend/known to work? The README file mentions GCC
2.95.3, but this one has problems as well, AFAIK.
>On Tue, 11 Nov 2003 10:27:16 +1100, Peter Lieverdink
><[email protected]> said:
>
> > I agree that something is very broken, though. Mind you, I can only
> > replicate this problem on one of my machines - the other one I've tried it
> > on seems to work fine. Odder still, when I compile a kernel on the machine
> > which is fine and ruin said kernel on the machine which is not fine, I
> > don't experience the crash.
>
>At 11:15 11/11/2003, you wrote:
>That _really_ sounds like your "broken machine" is nothing more than a
>broken compiler (or possibly binutils, but compilers tend to be more
>fragile by far, so it's more likely the compiler).
>
>What compiler versions do you have installed on the broken vs good
>machines?
>
>At 13:50 11/11/2003, you wrote:
>Could we see a 'gcc -V' from *both* machines, please? (and an 'as -v'
>and 'ld -v' as well, just to be thorough?)
They're the same. Both boxes use Debian Sid with gcc-3.3.2. I made sure
they were both running the same versions of gcc/binutils when I tested it.
When I use gcc-2.95.4 (gcc version 2.95.4 20011002 Debian prerelease) on
the "broken" machine I get a crash at the same point, but with different
output. (not captured, due to got annoyed and gave up) I can probably spend
an hour or so recompiling and capturing said crash if you want me to.
As for software versions (kahlua is "bad", shiraz is "good")
root@kahlua:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.2/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.2 (Debian)
root@kahlua:~$ as -v
GNU assembler version 2.14.90.0.7 (i386-linux) using BFD version
2.14.90.0.7 20031029 Debian GNU/Linux
root@kahlua:~$ ld -v
GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux
root@shiraz:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.2/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.2 (Debian)
root@shiraz:~$ as -v
GNU assembler version 2.14.90.0.7 (i386-linux) using BFD version
2.14.90.0.7 20031029 Debian GNU/Linux
root@shiraz:~$ ld -v
GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux
As you see, versions are identical on both machines - this is what had me
baffled. Every single other thing works fine on the "bad" machine, so I
tend to not suspect a hardware problem.
- Peter.
On Tue, 11 Nov 2003, Peter Lieverdink wrote:
> >At 13:50 11/11/2003, you wrote:
> >Could we see a 'gcc -V' from *both* machines, please? (and an 'as -v'
> >and 'ld -v' as well, just to be thorough?)
>
> They're the same. Both boxes use Debian Sid with gcc-3.3.2.
[ Taa-daa-taa-daa.. Theme from "The Twilight Zone" ]
And yet the kenrel works when built on one machine?
I'd love to see what the differences are. If the .config etc are all 100%
the same, I'd like to see what "diff" reports on the generated vmlinux
files (well, to be honest, I'd need either both files on some web-site, or
you to actually run diff and find _where_ the differences are).
Linus
At 03:49 12/11/2003, you wrote:
>On Tue, 11 Nov 2003, Peter Lieverdink wrote:
> > >At 13:50 11/11/2003, you wrote:
> > >Could we see a 'gcc -V' from *both* machines, please? (and an 'as -v'
> > >and 'ld -v' as well, just to be thorough?)
> >
> > They're the same. Both boxes use Debian Sid with gcc-3.3.2.
>
>[ Taa-daa-taa-daa.. Theme from "The Twilight Zone" ]
>
>And yet the kenrel works when built on one machine?
>
>I'd love to see what the differences are. If the .config etc are all 100%
>the same, I'd like to see what "diff" reports on the generated vmlinux
>files (well, to be honest, I'd need either both files on some web-site, or
>you to actually run diff and find _where_ the differences are).
>
> Linus
Well, due to [insert long explanation] the -test8 kernel wasn't available.
The "good" machine built a -test9, which crashed as well. *sigh* Mind you,
there are differences between the kernel _it_ builds and the one built by
the "bad" machine. I've uploaded a alien -t'd debian kernel packages to the
fastest web space I have for you to have a peek, if you have some time.
(what with lawsuits and whatnot ;-)
2.6.0-test9 built on the "good" box:
http://monolith.dnsalias.org/~cafuego/kernel-image-2.6.0-test9-kahlua.1.tgz
2.6.0-test9 built on the "bad" box:
http://monolith.dnsalias.org/~cafuego/kernel-image-2.6.0-test9-kahlua.2.tgz
More importantly though, the post from Jindrich:
At 00:13 16/11/2003, you wrote:
>I can confirm, having similar problem. I am using Debian Sid &
>2.6.0-test9, with 4Gig highmem support (1.5G physical RAM). When reading
>from cryptoloop (dd if=/dev/loop0 of=testoutput), it seems to produce only
>noise. Each run of dd produces completely different heap of garbage. When
>I disable highmem, getting rid of about 512 Megs, cryptoloop seems to work
>as expected - I can do losetup & mke2fs & mount & read/write files &
>unmount & losetup -d & again.. ad nauseam.
>
>Jindrich Makovicka
When I compiled on the "bad" machine with disabled HIGHMEM, the resultant
kernel has NO problems with cryptoloop. I can make a cryptoloop fs, mount,
copy, unmount, remount etc. That kernel is at:
http://monolith.dnsalias.org/~cafuego/kernel-image-2.6.0-test9-kahlua.3.tgz
So I guess HIGHMEM breaks cryptoloop somehow.
- Peter.
On Tue, 2003-11-11 at 10:27, Peter Lieverdink wrote:
> At 09:41 11/11/2003, you wrote:
> >In article <[email protected]>,
> >Florian Weimer <[email protected]> wrote:
> >| Soeren Sonnenburg wrote:
> >|
> >| > losetup -e blowfish /dev/loop0 /file
> >| > Password:
> >| > mkfs -t ext3 /dev/loop0
> >| > mount /dev/loop0 /mnt
> >| > <error unknown fs type>
> >| > <from here something was seriously broken... could not reboot anymore>
> >|
> >| I'm seeing something similar, but in my case, mke2fs already crashes.
> >|
> >| > system is:
> >| > Linux no 2.6.0-test7 #8 Sun Oct 26 17:00:49 CET 2003 ppc GNU/Linux
> >|
> >| Mine ist -test9 on x86.
> >|
> >| Have you found a solution in the meantime?
> >
> >I have been using aes and not seeing this. I suppose it's unlikely that
> >there could be an error in the kernel crypto, but I think I'll wait and
> >try blowfish on a non-critical machine.
>
> My solution has been to not use cryptofs, it crashes with whatever
> algorithm I choose :-(
I've been using 'highmem=off' until now, which provided a workaround.
Just built 2.6.1-rc1-mm2 and cryptloop+highmem works as it should now.
- peter.
Am Die, 2004-01-06 um 11.36 schrieb Peter Lieverdink:
> On Tue, 2003-11-11 at 10:27, Peter Lieverdink wrote:
> > At 09:41 11/11/2003, you wrote:
[...]
> > My solution has been to not use cryptofs, it crashes with whatever
> > algorithm I choose :-(
>
> I've been using 'highmem=off' until now, which provided a workaround.
> Just built 2.6.1-rc1-mm2 and cryptloop+highmem works as it should now.
FYI, cryptoloop works as expected in 2.6.0-mm2 both with and without
highmem support.
A vanilla 2.6.0 ist unusable due to oopses / data corruption (don't fsck
a cryptoloop device!) (again, with and without highmem).
I hope the -mm loop fixes will be included in 2.6.1.
HAND
--
Matthias Hentges
Cologne / Germany
[http://www.hentges.net] -> PGP welcome, HTML tolerated
ICQ: 97 26 97 4 -> No files, no URL's
My OS: Debian Woody. Geek by Nature, Linux by Choice