Bug#861115: Please consider increasing net.ipv6.route.max_size default value
Hi Tim, On 1/21/20 6:58 PM, Tim Bray wrote: I also agree. I've just spent a month tracking down an issue where IPv6 networking connections hang. Using Debian buster, 4.19.0-6-amd64. I also had fun finding a workaround for this bug, back in December, but I originally noticed some weirdness in v4.9 (neighbor being gc'ed immediately, possibly due to route falling out of cache). The below messages seams related: Basil Fillan on the bird-users list[1]: > We've also experienced this after upgrading a few routers to Debian > Buster. With a kernel bisect we found that a bug was introduced in the > following commit: > > 3b6761d18bc11f2af2a6fc494e9026d39593f22c > > This bug was still present in master as of a few weeks ago. > > It appears entries are added to the IPv6 route cache which aren't > visible from "ip -6 route show cache", but are causing the route cache > garbage collection system to trigger extremely often (every packet?) > once it exceeds the value of net.ipv6.route.max_size. [...] commit 3b6761d18bc11f2af2a6fc494e9026d39593f22c Author: David Ahern Date: Tue Apr 17 17:33:20 2018 -0700 net/ipv6: Move dst flags to booleans in fib entries Continuing to wean FIB paths off of dst_entry, use a bool to hold requests for certain dst settings. Add a helper to convert the flags to DST flags when a FIB entry is converted to a dst_entry. Signed-off-by: David Ahern Signed-off-by: David S. Miller Brian Rak on the netdev list[2]: I have net.ipv6.route.max_size=4096, and the machine only has 376 routes (calculated by `ip -6 route | wc -l`). However, raising this sysctl to 65k seems to instantly fix IPv6 (I'm not sure if this is a permanent fix yet) I also found an older thread[3] from 2014 on netdev, that revolves around the same topic as this bug, but it's might only share the workaround. [1] Re: IPv6 BGP & kernel 4.19 https://bird.network.cz/pipermail/bird-users/2020-February/014270.html [2] Re: IPv6 neighbor discovery issues on 4.18 (and now 4.19) https://lore.kernel.org/netdev/de54e925-9536-f2cc-7b89-7205b3fb2...@gameservers.com/ [3] IPv6 routing table max_size badly dimensioned compared to IPv4 https://lore.kernel.org/netdev/20140227192403.ga13...@xs.powerdns.com/ -- Best regards Asbjørn Sloth Tønnesen Network Engineer Fiberby ApS - AS42541
Re: [PATCH v2] kbuild, deb-pkg: support overriding userland architecture
On 12/09/2010 02:24 PM, maximilian attems wrote: On Wed, Dec 08, 2010 at 09:35:50PM +, Asbjoern Sloth Toennesen wrote: Usefull if building for sparc64 userland, because the sparc and sparc64 userlands use the same 64-bit kernel, making it impossible to always select the correct userland architecture for the resulting debian package. Might also be usefull, if you want a i386 userland with a amd64 kernel. Example usage: make DEBARCH=i386 deb-pkg hmm the conclusion was to prepend a KBUILD_ prefix for a kbuild variable? Any reason why that was overlooked? I checked man devscripts and saw yet no definition of DEBARCH, but in order not to have any potential conflicts and to keep namespase sane I think it is very much preferred to use KBUILD_DEBARCH. Sorry, I forgot it, patch comming up. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d00f473.9090...@asbjorn.biz
Re: [PATCH v3] kbuild, deb-pkg: support overriding userland architecture
On 12/09/2010 03:34 PM, Michal Marek wrote: On 9.12.2010 16:24, Asbjoern Sloth Toennesen wrote: Usefull if building for sparc64 userland, because the sparc and sparc64 userlands use the same 64-bit kernel, making it impossible to always select the correct userland architecture for the resulting debian package. Might also be usefull, if you want a i386 userland with a amd64 kernel. Example usage: make KBUILD_DEBARCH=i386 deb-pkg LKML-reference: alpine.deb.2.02.1011051437500.13...@aurora.sdinet.de Signed-off-by: Asbjoern Sloth Toennesen asbj...@asbjorn.biz Reviewed-by: WANG Cong xiyou.wangc...@gmail.com Acked-by: maximilian attems m...@stro.at --- Documentation/kbuild/kbuild.txt |8 scripts/package/builddeb|3 +++ 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 634c625..9cf3bf0 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -60,6 +60,14 @@ But some architectures such as x86 and sparc have aliases. x86: i386 for 32 bit, x86_64 for 64 bit sparc: sparc for 32 bit, sparc64 for 64 bit +KBUILD_DEBARCH +-- +For the deb-pkg target, allows overriding the normal heuristics deployed by +deb-deb. Normally deb-pkg attempts to guess the right architecture based on ^^^ deb-pkg? Sure. Anything else before I make a v4? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d00f8cf.7010...@asbjorn.biz
Re: [PATCH] kbuild, deb-pkg: support overriding userland architecture
Hi Max, On 12/03/2010 05:48 PM, maximilian attems wrote: On Sat, 06 Nov 2010, Asbjoern Sloth Toennesen wrote: Usefull if building for sparc64 userland, because the sparc and sparc64 userlands use the same 64-bit kernel, making it impossible to always select the correct userland architecture for the resulting debian package. Might also be usefull, if you want a i386 userland with a amd64 kernel. Example usage: make DEBARCH=i386 deb-pkg This patch is based on my 'kbuild, deb-pkg: select userland architecture based on UTS_MACHINE' patch. care to repost with KBUILD_ prefix, to keep namespace sane and mention in Documentation/kbuild/kbuild.txt together with the relevant acks. It be really cool to have that in next 2.6.38. Sure its on my todo for the weekend, have just had an insane week. I just noticed the armhf port effort yesterday, that would also need this patch, I will add your Ack-by when sending the updated patch. I also have a bunch of e1000e cleanups scheduled for 2.6.38, will submit to netdev this weekend as well. Thanks, for the reminding effort. -- Best regards Asbjørn Sloth Tønnesen asbjorn.biz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cf946f5.6040...@asbjorn.biz
Re: [PATCH] kbuild, deb-pkg: select userland architecture based on UTS_MACHINE
On 11/05/2010 01:42 PM, Sven-Haegar Koch wrote: On Fri, 5 Nov 2010, Asbjoern Sloth Toennesen wrote: Instead of creating the debian package for the compiling userland, create it for a userland matching the kernel thats being compiled. Eg. with this patch the following make command: make ARCH=i386 deb-pkg will output an i386 Debian package instead of an amd64 one, when run on an amd64 machine. How do I either select a differnet package-arch or reverse to the current way? I am right now using 'make ARCH=x86_64 deb-pkg' on a 32bit userspace environment running with a 64bit kernel, wanting to create packages to be installed in this i386 arch. (As I want 64bit support where possible (mostly for AES-NI support in dm-crypt), but don't have the time available to do a complete userspace reinstall and reconfiguration) Sounds like an one off thing, so in your case forcing the installation should work: dpkg --force-architecture linux-image-*.deb The problem with that approach is that it doesn't work with APT, but I doubt that there are any private APT repositories with this environment. The issue with one kernel and 2 userspaces will also arise in sparc, when the sparc64 userland gets going. So it will need to be dealt with at some point, so I create a 3 lines additional patch for it. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd5a6c8.8030...@asbjorn.biz
Re: [PATCH] kbuild, deb-pkg: select userland architectire based on UTS_MACHINE
On 11/05/2010 12:32 PM, Asbjoern Sloth Toennesen wrote: kbuild, deb-pkg: select userland architectire based on UTS_MACHINE s/architectire/architecture/g -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd3fc3a.4050...@asbjorn.it
Re: [PATCH] kbuild, deb-pkg: select userland architectire based on UTS_MACHINE
On 11/05/2010 12:41 PM, maximilian attems wrote: On Fri, Nov 05, 2010 at 12:32:41PM +, Asbjoern Sloth Toennesen wrote: Instead of creating the debian package for the compiling userland, create it for a userland matching the kernel thats being compiled. This patch supports all Lenny release architectures, and Linux-based architecture candidates for Squeeze. If it can't find a proper Debian userspace it displays a warning, and fallback to let deb-gencontrol use the host's userspace arch. Eg. with this patch the following make command: make ARCH=i386 deb-pkg will output an i386 Debian package instead of an amd64 one, when run on an amd64 machine. Signed-off-by: Asbjoern Sloth Toennesen asbj...@asbjorn.biz thank you, indeed very cool. Thanks. [...] +case $UTS_MACHINE in +i386|ia64|alpha|hppa) +debarch=$UTS_MACHINE ;; small nitpick parisc* != hppa Right, hppa should be by it self. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd406c7.8090...@asbjorn.biz
Re: [PATCH] kbuild, deb-pkg: fix Architecture field when cross compiling
On 11/04/2010 05:58 AM, Sam Ravnborg wrote: On Thu, Nov 04, 2010 at 03:44:04AM +, Asbjoern Sloth Toennesen wrote: [...] +# Attempt to find the correct Debian architecture +local forcearch= debarch= +case $ARCH in +i386|ia64) +debarch=$ARCH ;; +x86_64) +debarch=amd64 ;; On the commandline I can say ARCH=x86 - will it do the right thing then? No, not if you are cross compiling since ARCH=x86 isn't specific to either, we would have to look at the config. In that case it is better to do something like: x86|i386|x86_64) debarch=$(grep -q CONFIG_64BIT=y .config echo amd64 || echo i386) ;; +*) +grep -q CONFIG_ARM=y .config +debarch=arm$(grep -q CONFIG_AEABI=y .config echo el) +esac sparc may be know as sparc32, sparc64 and sparc these days. I recall that at least in the past debian supported sparc. I only included the major Debian architectures in my patch since, I don't know enough about all the smaller architectures and there config dependencies. I have however added mips as it seemed straight forward. AFAICT there are some problems surrounding sparc, since sparc in debian uses 64-bit kernels, 32-bit userland, and the new sparc64 port uses 64-kernels and 64-bit userland, so we have no way of knowing if the 64-bit sparc kernel should have the Architecture field set to sparc or sparc64. For now I will just set it to sparc, as that is a release candidate for squeeze, where sparc64 isn't nearly that far along. sparc*) debarch=sparc ;; mips) debarch=mips$(grep -q CPU_LITTLE_ENDIAN echo el) ;; I will sum these up in a new revision of the patch, when I get an ack from Michal or a Debian kernel team member. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd2a725.7030...@asbjorn.biz
Re: [PATCH] kbuild, deb-pkg: fix Architecture field when cross compiling
On 11/04/2010 12:36 PM, Michal Marek wrote: On 4.11.2010 13:29, Asbjørn Sloth Tønnesen wrote: No, not if you are cross compiling since ARCH=x86 isn't specific to either, we would have to look at the config. In that case it is better to do something like: x86|i386|x86_64) debarch=$(grep -q CONFIG_64BIT=y .config No, you should use $UTS_MACHINE (`uname -m` in the resulting kernel), like make rpm-pkg does, and only translate x86_64 to amd64. Ok, sorry, hadn't caught that it was on the resulting kernel. So that solves the x86 architectures, but according to a quick git grep, .config analysis is still needed for arm(el) and mips(el). -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd2b646.3090...@asbjorn.biz
Re: [PATCH] kbuild, deb-pkg: fix Architecture field when cross compiling
On 11/03/2010 10:57 PM, Michal Marek wrote: I know very little about debian packaging, but shouldn't this be done in all cases, regardless of CROSS_COMPILE being set or not? You even show in the above example that in some cases you don't need CROSS_COMPILE to build a kernel for a different architecture. I had a problem earlier with Kbuild ignoring ARCH if CROSS_COMPILE wasn't set, but can't reproduce with the current kernel, but I also started out with upgrading it from .26, since squeezes .32 doesn't work on Soekris net4501. So this is no longer an issue. The other reason for make it dependent on CROSS_COMPILE at least to begin with is that the ARCH - debarch translation table doesn't have to be as complete since it doesn't break anything in the currently working non-cross compile senario. If this doesn't matter then I will send a new patch, that doesn't depend on CROSS_COMPILE being set. I have CC'ed the debian-kernel list, for people not on LKML: https://patchwork.kernel.org/patch/296182/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd20f85.7040...@asbjorn.biz
Re: [PATCH] kbuild, deb-pkg: fix Architecture field when cross compiling
On 11/04/2010 02:42 AM, Asbjoern Sloth Toennesen wrote: + case $SUBARCH in + arm) debarch=$(grep -q CONFIG_AEABI=y .config \ + echo armel || echo arm) ;; + esac Hmm, didn't test the ARM part of that patch properly SUBARCH isn't available to builddeb. Will reply to this mail with fixed patch. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd22acf.1000...@asbjorn.it
Bug#523735: please release support for post-lenny kernel-package out of the box
retitle 523735 thanks The BTS contains patches fixing 12 bugs. The prepend tag is defined as A solution to this bug has been found and an upload will be made soon.. I don't know if you would define 5 months and counting as soon, I wouldn't at least not in that context. An alternative fix would be to open an wishlist bug on kernel-package to add a check if an initrd was generated, and trigger initramfs-tools if it wasn't but was build with --initrd, or just remove the option entirely. Which properly more likely to trigger an NMU than getting implemented. I have requested the title to changed to present this bug correctly I think a new initramfs-tools upload is long overdue. 2009 Apr 7 - kernel-package (k-p) 12.001 released to _experimental_ by Manoj Srivastava (srivasta, k-p maint) released 2009 Apr 12 - Antti-Juhani Kaijanaho created this bug 2009 Apr 12 - srivasta released kernel-package 12.003 to _unstable_ 2009 Apr 15 - Meelis Roos adds a short comment about an incompatible k-p now being in unstable ... long discussion ... 2009 Apr 24 - k-p 12.009 migrated to squeeze ... long discussion ... 2009 July 2 - Matthijs Kooijman CC'ed srivasta on this initramfs-tools bug 2009 July 2 - srivasta / k-p maint joins discussion ... discussion continues ... 2009 Aug 20 - k-p maint gives the KERNEL_PACKAGE_VERSION idea thumbs up 2009 Aug 21 - srivasta commited a patch to kernel-package for adding the required enviroment variable and released k-p 12.018 2009 Aug 23 - Matthijs Kooijman acked the k-p upload 2009 Sep 3 - k-p 12.020 migrated to _squeeze_ 2009 Sep 25 - Maximilian Attems (maks) tags this bug as pending and commits a fix 2009 Sep 28 - maks adds comment about the commit 2009 Sep 30 - maks recieves feedback, fixes a bug in the script and adds some comments. 2009 Oct 1 - Matthijs Kooijman confirmed the bug fix 2010 Mar 22 - The BTS contains patches fixing 12 bugs and 102 bugs on this package in total -- Best regards Asbjørn Sloth Tønnesen http://asbjorn.it/ signature.asc Description: OpenPGP digital signature
Bug#534880: do we want to fix this?
2) Abandon lenny for dom0 use / wait until stable-2.6.32 is in squeeze.
Packages are beginning become availible for testing
(huge thanks to Bastian Blank)
3) Get jeremy's 2.6.31 or 2.6.32 tree packaged and into lenny-backports
(together with xen-hypervisor-3.4-{i386,amd64})
I doubt that this bug is going to be fixed in 2.6.26, so I'm mostly for
getting stable-2.6.31 into backports since stable-2.6.32 isn't quite ther=
e.
Packages for testing based on stable-2.6.32 targeted for squeeze:
http://www.mail-archive.com/debian-kernel@lists.debian.org/msg53393.html
jeremy's stable=3D2.6.31 tree:
http://git.kernel.org/?p=3Dlinux/kernel/git/jeremy/xen.git;a=3Dshortlog;h=
=3Drefs/heads/xen/stable-2.6.31.x
jeremy's stable-2.6.32 tree:
http://git.kernel.org/?p=3Dlinux/kernel/git/jeremy/xen.git;a=3Dshortlog;h=
=3Drefs/heads/xen/stable-2.6.32.x
--=20
Best regards
Asbj=F8rn Sloth T=F8nnesen
signature.asc
Description: OpenPGP digital signature
