[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2.6.19, kernel-package problems and what are our plans for etch ...



I think it is a good ideea to adopt 2.6.19 for etch if its possible. I
looked over the changelogs in 2.6.18 and there is one issue that
concerns me:

commit a4fce7747b167aa5e9aa43c4f816744d8a97e021
Author: Patrick McHardy <kaber@trash.net>
Date:   Wed Oct 11 01:53:26 2006 -0700

   NETFILTER: NAT: fix NOTRACK checksum handling

   The whole idea with the NOTRACK netfilter target is that
   you can force the netfilter code to avoid connection
   tracking, and all costs assosciated with it, by making
   traffic match a NOTRACK rule.

   But this is totally broken by the fact that we do a checksum
   calculation over the packet before we do the NOTRACK bypass
   check, which is very expensive.  People setup NOTRACK rules
   explicitly to avoid all of these kinds of costs.

   This patch from Patrick, already in Linus's tree, fixes the
   bug.

   Move the check for ip_conntrack_untracked before the call to
   skb_checksum_help to fix NOTRACK excemptions from NAT. Pre-2.6.19
   NAT code breaks TSO by invalidating hardware checksums for every
   packet, even if explicitly excluded from NAT through NOTRACK.

   2.6.19 includes a fix that makes NAT and TSO live in harmony,
   but the performance degradation caused by this deserves making
   at least the workaround work properly in -stable.

On 12/2/06, Sven Luther <sven.luther@wanadoo.fr> wrote:
On Sat, Dec 02, 2006 at 10:37:01AM +0100, Andreas Barth wrote:
> * Sven Luther (sven.luther@wanadoo.fr) [061201 20:30]:
> >   - What is stopping 2.6.18 to enter testing ? The PTS says "Should ignore,
> >     but forced by vorlon", so does this mean it will enter testing today ?
> >     What about the remaining (or new) RC bugs ? Some of them being open
> >     against 2.6.17, so also present in testing.
>
> If one of the release managers uses the force-hint, nothing from the
> first stage (RC-bugs, date, out-of-date, ...) will block the testing
> migration anymore.
>
> However, in the second stage, installability is checked. According to
> todays output, these packages are broken by the transition:
> trying: linux-2.6
> skipped: linux-2.6 (15 <- 32)
>     got: 115+0: i-115
>     * i386: kernel-image-2.6-386, kernel-image-2.6-686, kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, linux-headers-2.6-k7, linux-headers-2.6-vserver-686, linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, linux-image-686, linux-image-686-bigmem, linux-image-k7, linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, redhat-cluster-modules-2.6.17-2-686, redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, redhat-cluster-modules-2.6.17-2-vserver-686, redhat-cluster-modules-2.6.17-2-vserver-k7, redhat-cluster-modules-2.6.17-2-xen-686, redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, squashfs-modules-2.6-vserver-k7, squashfs-modules-2.6-xen-686, squashfs-modules-2.6-xen-k7, squashfs-modules-2.6.17-2-486, squashfs-modules-2.6.17-2-686, squashfs-modules-2.6.17-2-686-bigmem, squashfs-modules-2.6.17-2-k7, squashfs-modules-2.6.17-2-vserver-686, squashfs-modules-2.6.17-2-vserver-k7, squashfs-modules-2.6.17-2-xen-686, squashfs-modules-2.6.17-2-xen-k7, unionfs-modules-2.6-486, unionfs-modules-2.6-686, unionfs-modules-2.6-686-bigmem, unionfs-modules-2.6-k7, unionfs-modules-2.6.17-2-486, unionfs-modules-2.6.17-2-686, unionfs-modules-2.6.17-2-686-bigmem, unionfs-modules-2.6.17-2-k7
>
> I could use a force-hint on linux-modules-extra-2.6 as well, but as long
> as it is out-of-date on so many architectures, that won't improve the
> picture. And also, why do e.g. linux-image-2.6-vserver-k7 get
> uninstallable (hm, that could be a bug in britney though).

Ok, this is the linux-modules-extra-2.6 problem, which should be solved by
removing the module which is broken. not sure which one it was.

The -k7 issue, i don't know, can it be a flavour that was dropped or something ?

> >   - What are our plans for 2.6.19 ? Will we have it enter unstable, and
> >     maintain the etch kernel through testing-proposed-updates ? I heard this
> >     mentioned some time back. Will we fork a linux-2.6.19 package in unstable
> >     ? Will we keep 2.6.19 in experimental for now ?
>
> I hope you can keep 2.6.19 in experimental for now - it doesn't take so
> long to release Etch anymore.

Bah, we where told this for sarge, and it took over a year back then. I don't
see us releaseing etch anytime soon, since we don't have had a single release
candidate of d-i with the 2.6.18 kernels in it yet, so moving 2.6.19 to
unstable (maybe with a linux-2.6.19 source package) should be nice enough. We
did this already for 2.6.16, so, we know how to do this.

Friendly,

Sven Luther

--
Teodor-Adrian MICU
Consultant TI&C
teodor.micu@Gmail.com

Reply to: