Hi Denis,
the new i386 memcpy macro is a ticking timebomb.
I've been debugging a new mISDN crash, just to find out that a memcpy
was not inlined correctly.
Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
This source code:
mISDN_pid_t pid;
[...]
Hi Andrew,
> - Nobody said anything about the PM resume and DRI behaviour in
> 2.6.12-rc1-mm4. So it's all perfect now?
Yes, works for me. DRI (i915) is working again and USB is now happy
after a PM resume too.
signature.asc
Description: This is a digitally signed message part
Am Mittwoch, den 06.04.2005, 13:14 +0300 schrieb Denis Vlasenko:
> Oh shit. I was trying to be too clever. I still run with this patch,
> so it must be happening very rarely.
Yes, that's right, it happened with code that's not in the mainline tree
but could have happened anywhere.
> Does this on
Am Mittwoch, den 09.02.2005, 17:19 -0800 schrieb Andrew Morton:
> > It must be
> > possible to process more than 2 mappings in softirq context.
>
> Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
> arbitrarily large number of them then no, we cannot do that.
>
> Possibl
Am Dienstag, den 25.01.2005, 18:28 +0100 schrieb Michael Buesch:
> I set up swap on an encrypted dmcrypt device.
> While stressing swap usage with make -j200 in the
> kernel tree, the machine crashes:
>
> Adding 1461872k swap on /dev/mapper/swap. Priority:-2 extents:1
> [ cut here ]-
Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall:
> From looking at the dm_crypt code, it appears that it can be
> interrogated to report the current key. Some quick testing shows:
>
> # dmsetup table /dev/mapper/volume1
> 0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0
Am Mittwoch, den 02.02.2005, 17:52 -0800 schrieb Matt Mackall:
> > An alternativ would be to use some form of handle to point to the key
> > after it has been given to the kernel. But that would require some more
> > infrastructure.
>
> There's been some talk about such infrastructure already. I
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
> On Thu, Feb 03, 2005 at 03:34:29AM +0100, Christophe Saout wrote:
> > The keyring API seems very flexible. You can define your own type of
> > keys and give them names. Well, the name is probably irrelevant here an
Hi,
I was investigating a way to hide the dm-crypt key from device-mapper
configuration IOCTLs since the key might accidentally end up somewhere
it shouldn't (see other thread).
Then I stumbled across the new key retention service. This is exectly
what I was looking for.
The idea is to add the c
Am Mittwoch, den 02.02.2005, 20:05 -0800 schrieb Matt Mackall:
> Dunno here, seems that having one tool that gave the kernel a key named
> "foo" and then telling dm-crypt to use key "foo" is probably not a bad
> way to go. Then we don't have stuff like "echo | dmsetup create"
> and the like and t
rs are 64 bit the compiler might
need to extend to adjust the size of the operands for the address
calculation. Right?
Since size_t is unsigned I also had to modify the two loops since I
can't check for any of the variables becoming negative. Tested with all
kinds of array sizes.
Signed-off-by
Am Dienstag, den 08.03.2005, 00:08 -0500 schrieb Kyle Moffett:
> Did you include support for the new key/keyring infrastructure
> introduced
> a couple versions ago by David Howells? It allows userspace to create
> and
> manage various sorts of "keys" in kernelspace. If you create and
> regis
Hi,
> +x86_64-fix-config_preempt.patch
>
> x86_64-fix-config_preempt.patch
> x86_64: Fix CONFIG_PREEMPT
Has this one been stress-tested?
I've got the impression that things have become a lot worse.
I've been seeing things like these:
Mar 25 01:00:48 websrv2 REISERFS: panic (device dm-1): clm
eproducible filesystem errors I've seen (with reiserfs, which
heavily relies on the BKL).
Signed-off-by: Christophe Saout <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm2.orig/arch/x86_64/kernel/entry.S2005-03-24
17:32:22.0 +0100
+++ linux-2.6.12-rc1-mm2/arch/x86_64/kernel/
Hi Robert,
it looks like you shouldn't call iput with spinlocks held. iput might
call down into the filesystem to delete the inode and this can sleep.
Mar 27 14:38:18 server Debug: sleeping function called from invalid
context at include/asm/semaphore.h:102
Mar 27 14:38:18 server in_atomic():1, i
Am Sonntag, den 27.03.2005, 19:26 +0200 schrieb Andi Kleen:
> > preempt_schedule_irq is not an i386 specific function and seems to take
> > special care of BKL preemption and since reiserfs does use the BKL to do
> > certain things I think this actually might be the problem...?
>
> Hmm, preempt_s
Am Montag, den 22.01.2007, 11:56 -0800 schrieb Andrew Morton:
> There has been a long history of similar problems when raid and dm-crypt
> are used together. I thought a couple of months ago that we were hot on
> the trail of a fix, but I don't think we ever got there. Perhaps
> Christophe can c
Fix corruption issue with dm-crypt on top of software raid5. Cancelled
readahead bio's that report no error, just have BIO_UPTODATE cleared
were reported as successful reads to the higher layers (and leaving
random content in the buffer cache). Already fixed in 2.6.19.
Signed-off-by: Chris
Am Freitag, den 01.12.2006, 19:49 -0800 schrieb Chris Wright:
> * Christophe Saout ([EMAIL PROTECTED]) wrote:
> > Fix corruption issue with dm-crypt on top of software raid5. Cancelled
> > readahead bio's that report no error, just have BIO_UPTODATE cleared
> > were re
19 matches
Mail list logo
