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 Deb
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 y
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 ju
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
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 se
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 wh
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
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 tes
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
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 att
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
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 (device_se
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
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
