Your kernel stack trace looks similar to mine with an RX480 under a recent
5.8.x kernel. I solved that oops in the power management routines by
turning power management off. Append "amdgpu.runpm=0 amdgpu.bapm=0
amdgpu.dpm=0 amdgpu.aspm=0" to your kernel boot parameters. In addition,
you might also
Binary patch PCI-IDs:
dd bs=1 count=73332 if=e1000e.ko head
dd bs=1 skip=73334 if=e1000e.ko tail
echo -ne \\0336\\0020 middle
cat head middle tail e1000e.ko
Works only with the 105756 sized binary from Lenny i386 release CDs.
You have to modprobe e1000e.ko manually, of course.
I like Debian
At Thu, 24 Jan 2008 17:09:19 +0100,
Clemens Fruhwirth wrote:
Today, I'm busy, but tomorrow I can rework the sanity checking for the
luksAddKey issue. Feel free to merge your man page patch! Then I might roll
another pre..
Ok, I pushed all changes to SVN. Would you like to try?
--
Fruhwirth
At Wed, 23 Jan 2008 16:51:45 +0100,
Jonas Meurer wrote:
btw, do you have pending changes which are not in the svn repository yet
(like the patch regarding slots from u.kuehn)? and what about releasing
cryptsetup 1.0.6?
Yes, and his merged patch was sitting on my disk for about 1 month. I just
At Mon, 21 Jan 2008 19:17:36 +0100,
Jonas Meurer wrote:
On 21/01/2008 Clemens Fruhwirth wrote:
Jonas Meurer wrote:
My main intention was to prevent multiple luksOpen'd devices, as this
(in my opinion) is usually not neccessary and most likely an
error. But using luksAddKey
At Wed, 3 Jan 2007 20:37:22 +0100,
Martin Michlmayr [EMAIL PROTECTED] wrote:
Well, it seems to fix the problem and according to the thread on lkml
the lack of flush_anon_page() on ARM is associated with some
corruption. At least FUSE doesn't work on ARM without those patches,
so it seems
At Tue, 2 Jan 2007 19:04:41 +0100,
Martin Michlmayr [EMAIL PROTECTED] wrote:
* Clemens Fruhwirth [EMAIL PROTECTED] [2007-01-02 18:00]:
Does luksDump report the same things on both architecture?
Yes.
After a bit of debugging on Gordon's slug, I found out that we have
some kind of read race
At Wed, 3 Jan 2007 20:14:42 +0100,
Martin Michlmayr [EMAIL PROTECTED] wrote:
* Clemens Fruhwirth [EMAIL PROTECTED] [2007-01-03 17:59]:
After a bit of debugging on Gordon's slug, I found out that we have
some kind of read race/read corruption when reading the encrypted
master key from
At Sat, 30 Dec 2006 14:13:42 +0100,
Martin Michlmayr [EMAIL PROTECTED] wrote:
* Clemens Fruhwirth [EMAIL PROTECTED] [2006-12-30 11:50]:
Is there anything else I should try?
foobar:~# cryptsetup luksOpen /dev/sda5 x
Enter LUKS passphrase:
device-mapper: table: 254:0: crypt: Device
At Tue, 2 Jan 2007 19:04:41 +0100,
Martin Michlmayr [EMAIL PROTECTED] wrote:
* Clemens Fruhwirth [EMAIL PROTECTED] [2007-01-02 18:00]:
Does luksDump report the same things on both architecture?
Yes.
Strange. Can I somehow gain access to your test box? I'm not entirely
out of guesses
At Fri, 29 Dec 2006 21:24:34 +0100,
Martin Michlmayr [EMAIL PROTECTED] wrote:
* Clemens Fruhwirth [EMAIL PROTECTED] [2006-12-29 11:52]:
Please try the version from subversion
http://luks.endorphin.org/svn/cryptsetup
With 1.0.4 plus the attached 2 patches from SVN I no longer get any
At Wed, 20 Dec 2006 17:15:29 +0100,
Martin Michlmayr [EMAIL PROTECTED] wrote:
We're seeing corruption of LUKS partition headers on ARM. I've
confirmed this on two different ARM platforms (IXP4xx and IOP32x) and
with 2.6.17 and 2.6.18.
Basically, when you create a LUKS partition on a PC and
Jonas Meurer [EMAIL PROTECTED] wrote:
i've tried to reproduce this bug, and indeed luksOpen fails for me with
a similar error message. i tried also plain dm-crypt, and discovered
that 'cryptsetup create' doesn't fail. the created device is mountable
and contains all the data which i put into
Jonas Meurer [EMAIL PROTECTED] wrote:
However, we fixed the bug. The problem was that I restricted the length
(number of sectors) of a temporary dm-crypt mapping. However for devices
with non-512 sector size like DVDs, the length as well as the start must
be aligned to
Jonas Meurer [EMAIL PROTECTED] wrote:
after upgrading cryptsetup I was not able to use luksOpen on a
DVD image file. Downgrading to 2:1.0.1-16 makes it work again,
so something in the upgrade broke things.
Here is the command line log with the old 1.0.1 version:
$ cryptsetup --readonly
Package: common-lisp-controler
Version: 4.15
asdf-install on Gentoo does not work. Gentoo packages asdf-install in
cl-asdf, and installs the package into common-lisp-controller's asdf
repository in /usr/share/common-lisp. SBCL comes with its own
implementation of asdf-install and must not use the
16 matches
Mail list logo
