headers
Jan Klod | 3 Dec 2007 21:30
Picon

My gentoo kernel hangs when used with loop-AES

Hallo,
I am running 2.6.22-gentoo-sources-r9 on loop-AESv3.2b encrypted root 
[system A]. The problem is that [A] hangs completely with no messages in 
/var/log/messages (freezes immediately after some hours operating) and I 
have no idea what exactly is wrong. Hangs are random.

What I have done already:
1. tested memory for 8 hours - no errors.
2. suspected my own kernel configuration, copied [A] to
non-encrypted partition, recompiled same kernel with same .config, using
genkernel [system B]. Tested it for nearly 24hours - no hang. Other
differences between those 2 systems:
 ______________________A, B
   kernel compile method: manually, genkernel using same .config
   kernel startup:                 initrd.gz, initramfs created by
genkernel

Can you help? I'll send necessary configurations and perform tests, but 
now there is no idea what else information would be useful.

-- 
Jan

--

-- 
gentoo-kernel <at> gentoo.org mailing list
Permalink | Reply | 0 comments |
headers
Daniel Drake | 14 Dec 2007 22:20
Picon
Favicon

[ANNOUNCE] genpatches-2.6.23-5 release

This is an automated email announcing the release of genpatches-2.6.23-5

CHANGES SINCE 2.6.23-4
-----------------------

Revision 1213: 
Fix flood of ACPI processor events. (dsd)
Added: 2205_acpi-processor-event-flood.patch

Revision 1214: 
Added uevent platform fix for bug 201157 (mpagano)
Added: 2600_uevent-platform-devices-fix.patch

Revision 1215: 
Add support for older firmware versions for the Nikon D200 camera (mpagano)
Added: 2500_usb-storage-nikon-d200-old-firmware.patch

Revision 1216: 
Linux 2.6.23.10 (dsd)
Added: 1009_linux-2.6.23.10.patch
Deleted: 2300_usb-sysfs-power-nodes.patch
Deleted: 2400_forcedeth-boot-delay.patch

Revision 1217: 
2.6.23-5 release (dsd)

PATCHES
-------

When the website updates, the complete patch list and split-out patches will be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Drake | 21 Dec 2007 20:21
Picon
Favicon

[ANNOUNCE] genpatches-2.6.23-6 release

This is an automated email announcing the release of genpatches-2.6.23-6

CHANGES SINCE 2.6.23-5
-----------------------

Revision 1218: 
Adding linux-2.6.23.11 and linux-2.6.23.12 (mpagano)

Revision 1219: 
Adding linux-2.6.23.11 and linux-2.6.23.12 patches (mpagano)
Added: 1010_linux-2.6.23.11.patch
Added: 1011_linux-2.6.23.12.patch

Revision 1220: 
2.6.23-6 release (dsd)

PATCHES
-------

When the website updates, the complete patch list and split-out patches will be
available here:
http://dev.gentoo.org/~dsd/genpatches/patches-2.6.23-6.htm
http://dev.gentoo.org/~dsd/genpatches/tarballs/genpatches-2.6.23-6.base.tar.bz2
http://dev.gentoo.org/~dsd/genpatches/tarballs/genpatches-2.6.23-6.extras.tar.bz2

ABOUT GENPATCHES
----------------

genpatches is the patchset applied to some kernels available in Portage.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Volkov | 27 Dec 2007 21:39
Picon
Favicon

Kernel patching solution.

Hello, list.

I just took maintenance of some ebuilds which require user to patch
kernel, e.g. l7-filter. Actually l7-filter is the ebuild which only task
is to patch kernel and I really hate the way it works:
 * it requires FEATURES="-sandbox"
 * you have to reemerge l7-filter after each kernel update
 * and other similar problems the root of which is that portage never
knows a kernel version the patch was already applied to.

So I'm thinking on solution to fix this problem. First I've tried to
rewrite ebuild to avoid FEATURES="-sandbox" and this is possible, but
does not fix other problems.

The best idea I could think of to the moment is similar to webapps.
emerge just installs patches to some known location while actual
patching will be done with some external utility - kernel-patcher.
Together with patching it will populate database with information about
patches to which kernels were installed. So if user decides to find out
what patches were installed to the kernel kernel-patcher will list that.
Also if user decides to upgrade kernel it'll be possible to call
kernel-patcher and suggest user to install patches, applied to currently
symlinked (/usr/src/linux) kernel too, thus simplifying kernel upgrade.

Well, I did not wrote all details I have in my head now, but before I've
started to work on/draft this this I wanted to hear some opinions as I'm
sure some of you already have thoughts about this. Is this feasible
solution? Are there better?

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Drake | 27 Dec 2007 22:05
Picon
Favicon

Re: Kernel patching solution.

Peter Volkov wrote:
> Well, I did not wrote all details I have in my head now, but before I've
> started to work on/draft this this I wanted to hear some opinions as I'm
> sure some of you already have thoughts about this. Is this feasible
> solution? Are there better?

I hate l7-filter and wish it would go away.

I would not suggest spending time on the problem, as if I hear that 
someone else is going to add a package that does something similar, I'll 
go and behead them.

As for other options: You could just install the patch to the filesystem 
and require the user to apply it. Other packages do/did this, e.g. hdaps

But the only real solution is this: get the patch merged upstream, or 
equivalent functionality offered in the mainline kernel. Everything else 
is working against the flow of the kernel.

Daniel

--

-- 
gentoo-kernel <at> gentoo.org mailing list
Permalink | Reply | 1 comment |
headers
Peter Volkov | 28 Dec 2007 07:51
Picon
Favicon

Re: Kernel patching solution.


В Чтв, 27/12/2007 в 21:05 +0000, Daniel Drake пишет:
> As for other options: You could just install the patch to the filesystem 
> and require the user to apply it. Other packages do/did this, e.g. hdaps

Ok. Let's me suggest another way. I'd like to standardize (eclass) the
place such ebuilds install patches. Together with place, I'd like to add
information (may be in patch name or inside patch itself) what kernels
this patch supports. Is this the way to go?

After this I'm sure there will be no problem to have external tool to
simplify patching. If you do not like it - do not use it.

> But the only real solution is this: get the patch merged upstream, or 
> equivalent functionality offered in the mainline kernel. Everything else 
> is working against the flow of the kernel.

Eh. I see your intentions. But IMQ will never get upstream while me and
many other people are using it and AFAIK currently there is not
substitution for it (IFB is different). patch-o-matic patches are really
slow in moving to official tree, while I have to use it's functionality.
There will be always such patches.

--

-- 
Peter.
Permalink | Reply | 0 comments |

Gmane