Re: [CFT] modular kernel config
Quoting Slawa Olhovchenkov s...@zxy.spb.ru (from Thu, 1 Mar 2012 18:58:34 +0400): On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Bye, Alexander. -- If you analyse anything, you destroy it. -- Arthur Miller http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: Quoting Slawa Olhovchenkov s...@zxy.spb.ru (from Thu, 1 Mar 2012 18:58:34 +0400): On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Not controllers, peripherals: disk/tape/etc device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
Quoting Slawa Olhovchenkov s...@zxy.spb.ru (from Fri, 2 Mar 2012 13:24:01 +0400): On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: Quoting Slawa Olhovchenkov s...@zxy.spb.ru (from Thu, 1 Mar 2012 18:58:34 +0400): On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Not controllers, peripherals: disk/tape/etc device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) They should be all in the cam module, they don't exist as separate modules. If something is missing, it's a bug or omitted on purpose (but then there's hopefully a comment somewhere explaining why). Bye, Alexander. -- BOFH excuse #418: Sysadmins busy fighting SPAM http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote: Hi, I created a kernel config for i386/amd64 (should work on -current and 9.x) and a suitable loader.conf which: - tries to provide as much features as GENERIC (I lost one or two disk controllers, they are not available as a module... or I didn't find them) - incorporates some more features based upon a poll on stable@ (see below) - loads as much as possible as a module I've compile-tested them on i386 and amd64, but I didn't had time yet to give it a try on a spare machine. I may get some time next week to test (i386 only). It would be nice if someone could help testing: - compile the kernel - make _sure_ you have a way to recover the system in case the new kernel+loader.conf fails - verify that the example loader.conf contains all devices which are important for you - copy the example loader.conf to /boot/loader.conf - give it a try You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I didn't provide direct links for eqch one on purpose. If you do not know how to recover a system with an unsuitable loader.conf, don't give this a try (you could check a diff between GENERIC and SMALL, and make sure all removed devices which are imporant for you are in the loader.conf). They should work on -current and on 9.x, for 8.x I'm not sure if it woll work without removing some stuff (GENERIC on 8.x comes without some more debugging options, make sure you don't get surprised by them, but those may not be the only differences). I didn't use the name MODULAR on purpose, I've chosen a name where the first letter does not yet exist in the kernel config directory, to make tab-completion more easy. If you are not happy with the name, keep your opinion for yourself please, until after you tested this on a (maybe virtual) system. The loader.conf was generated with a script from a diff between GENERIC and SMALL, if there's a name mismatch between the config-name and the module-name, the script may have missed the module (I added some missing sound modules, but I may have overlooked something). You better double-check before giving it a try. The loader.conf is also supposed to disable some features (at the end of the file) which are new compared to what is in GENERIC, if the particular feature could cause a change in behavior. The new stuff in the kernel config compared to GENERIC is (in order of number of requests from users): - IPSEC (+ device enc + IPSEC_NAT_T) - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) - BPF_JITTER In the poll there where some more options requested, but most of them can be handled via the loader or sysctl (e.g. the firewalls can be loaded as modules). For some of them I added some comments at the end of the SMALL config to make it more easy to find the correct way of configuring them. Doc-committers may want to have a look, maybe there's an opportunity to improve existing documentation. I'm interested in success reports, failure reports, and reports about missing stuff in loader.conf (mainly compared to the devices available in GENERIC, but missing stuff which could help getting a system installed and booted is welcome even if what you propose is not in GENERIC). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Just an idea : Ship FreeBSD with all the kernel object files (even compile different versions of them, let's say networking with IPFORWARD and networking without), and then let the user relink the kernel with some shell script. This way freebsd-update can binary update the object files, and then relink the users's kernel. This of course will probably need some infrastructure work to make it possible. P.S.: As I said, just an idea off the top of my head :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf Where SCSI disk/etc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
SunOS 4.x users will love you. :-) Adrian On 1 March 2012 02:27, Nikolay Denev nde...@gmail.com wrote: On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote: Hi, I created a kernel config for i386/amd64 (should work on -current and 9.x) and a suitable loader.conf which: - tries to provide as much features as GENERIC (I lost one or two disk controllers, they are not available as a module... or I didn't find them) - incorporates some more features based upon a poll on stable@ (see below) - loads as much as possible as a module I've compile-tested them on i386 and amd64, but I didn't had time yet to give it a try on a spare machine. I may get some time next week to test (i386 only). It would be nice if someone could help testing: - compile the kernel - make _sure_ you have a way to recover the system in case the new kernel+loader.conf fails - verify that the example loader.conf contains all devices which are important for you - copy the example loader.conf to /boot/loader.conf - give it a try You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I didn't provide direct links for eqch one on purpose. If you do not know how to recover a system with an unsuitable loader.conf, don't give this a try (you could check a diff between GENERIC and SMALL, and make sure all removed devices which are imporant for you are in the loader.conf). They should work on -current and on 9.x, for 8.x I'm not sure if it woll work without removing some stuff (GENERIC on 8.x comes without some more debugging options, make sure you don't get surprised by them, but those may not be the only differences). I didn't use the name MODULAR on purpose, I've chosen a name where the first letter does not yet exist in the kernel config directory, to make tab-completion more easy. If you are not happy with the name, keep your opinion for yourself please, until after you tested this on a (maybe virtual) system. The loader.conf was generated with a script from a diff between GENERIC and SMALL, if there's a name mismatch between the config-name and the module-name, the script may have missed the module (I added some missing sound modules, but I may have overlooked something). You better double-check before giving it a try. The loader.conf is also supposed to disable some features (at the end of the file) which are new compared to what is in GENERIC, if the particular feature could cause a change in behavior. The new stuff in the kernel config compared to GENERIC is (in order of number of requests from users): - IPSEC (+ device enc + IPSEC_NAT_T) - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) - BPF_JITTER In the poll there where some more options requested, but most of them can be handled via the loader or sysctl (e.g. the firewalls can be loaded as modules). For some of them I added some comments at the end of the SMALL config to make it more easy to find the correct way of configuring them. Doc-committers may want to have a look, maybe there's an opportunity to improve existing documentation. I'm interested in success reports, failure reports, and reports about missing stuff in loader.conf (mainly compared to the devices available in GENERIC, but missing stuff which could help getting a system installed and booted is welcome even if what you propose is not in GENERIC). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Just an idea : Ship FreeBSD with all the kernel object files (even compile different versions of them, let's say networking with IPFORWARD and networking without), and then let the user relink the kernel with some shell script. This way freebsd-update can binary update the object files, and then relink the users's kernel. This of course will probably need some infrastructure work to make it possible. P.S.: As I said, just an idea off the top of my head :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On Tue, Feb 28, 2012 at 10:37 PM, Alexander Leidinger alexan...@leidinger.net wrote: Quoting ~Lst slack...@gmail.com (from Tue, 28 Feb 2012 16:38:43 +0700): 2012/2/28 Steve Wills swi...@freebsd.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/12 10:53, Łukasz Wąsikowski wrote: W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. Agree, I've run into problems with FLOWTABLE (with just the features that were enabled by default in 8.0) when routers changed MAC addresses. As far as I understand it, FLOWTABLE is both broken and abandoned (but if I'm wrong, please let me know). So, IMHO, not only should it not be enabled by default, but given that it was disabled complete in 8.x after 8.0 (too lazy to look at exactly when right now), I think it shouldn't even be included, since that might encourage users to try it out only to encounter problems with it. Steve Definitely yes, I'd some problems too with FLOWTABLE running for router. So I have to disabled in kernel and sysctl. To make sure I understand you correctly: Did you disabled it with the sysctl/loader-tunable and everything was OK again, or did you had to remove it from the kernel config (disabling via sysctl was not enough) to resolve the issue? I have one report where a person has issue with FLOWTABLE, but disabling it via the sysctl/loader-tunable was enough to address his concerns. Bye, Alexander. I had to remove it from the kernel config and in my cased disabling via sysctl was not enough to resolve the issue Rgds, -- Lasta Yani ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
2012/2/29 Łukasz Wąsikowski luk...@wasikowski.net: W dniu 2012-02-28 22:22, Arnaud Lacombe pisze: FLOWTABLE on 8.x crashed BGP routers (kern/144917). no crash dump, no backtrace, no follow-up whatsoever after 1 year and 2 years, what's your points ? You could really have chosen a better PR to back up your argument... Sorry, but I don't want to bug trace this issue, simply because lack of time, resources and interest in this feature. I've run into this bug on production box, went through hell because of it and turned off flowtable which I do not use and not need. If this problem is still alive (it might be, the PR I've mentioned is still open) then it's not a good idea to turn on this feature by default. If you're interested in using this feature then feel free to debug and test. Give me a deterministic way to reproduce the issue and I will. Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). You need three peers sending you full Internet routing table (3x400k prefixes). Some people got it with only two peers. After a short while your CPU should stuck in 100% busy. -- best regards, Lukasz Wasikowski In my cased, I used OpenBGPD. Rgds, -- Lasta Yani ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
2012/2/28 Steve Wills swi...@freebsd.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/12 10:53, Łukasz Wąsikowski wrote: W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. Agree, I've run into problems with FLOWTABLE (with just the features that were enabled by default in 8.0) when routers changed MAC addresses. As far as I understand it, FLOWTABLE is both broken and abandoned (but if I'm wrong, please let me know). So, IMHO, not only should it not be enabled by default, but given that it was disabled complete in 8.x after 8.0 (too lazy to look at exactly when right now), I think it shouldn't even be included, since that might encourage users to try it out only to encounter problems with it. Steve Definitely yes, I'd some problems too with FLOWTABLE running for router. So I have to disabled in kernel and sysctl. Rgds, -- Lasta Yani ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
Quoting ~Lst slack...@gmail.com (from Tue, 28 Feb 2012 16:38:43 +0700): 2012/2/28 Steve Wills swi...@freebsd.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/12 10:53, Łukasz Wąsikowski wrote: W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. Agree, I've run into problems with FLOWTABLE (with just the features that were enabled by default in 8.0) when routers changed MAC addresses. As far as I understand it, FLOWTABLE is both broken and abandoned (but if I'm wrong, please let me know). So, IMHO, not only should it not be enabled by default, but given that it was disabled complete in 8.x after 8.0 (too lazy to look at exactly when right now), I think it shouldn't even be included, since that might encourage users to try it out only to encounter problems with it. Steve Definitely yes, I'd some problems too with FLOWTABLE running for router. So I have to disabled in kernel and sysctl. To make sure I understand you correctly: Did you disabled it with the sysctl/loader-tunable and everything was OK again, or did you had to remove it from the kernel config (disabling via sysctl was not enough) to resolve the issue? I have one report where a person has issue with FLOWTABLE, but disabling it via the sysctl/loader-tunable was enough to address his concerns. Bye, Alexander. -- The light at the end of the tunnel is the headlamp of an oncoming train. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
Hi, 2012/2/27 Łukasz Wąsikowski luk...@wasikowski.net: W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). no crash dump, no backtrace, no follow-up whatsoever after 1 year and 2 years, what's your points ? You could really have chosen a better PR to back up your argument... - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
Hi, 2012/2/27 Steve Wills swi...@freebsd.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/12 10:53, Łukasz Wąsikowski wrote: W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. Agree, I've run into problems with FLOWTABLE (with just the features that were enabled by default in 8.0) when routers changed MAC addresses. As far as I understand it, FLOWTABLE is both broken and abandoned (but if I'm wrong, please let me know). You will sure go really far with this kind of It is broken ? Let's not fix it and disable it instead mentality, even more when coming from a committer. As long as there will be these kind of comments around here, FreeBSD will deserve nothing but to keep dying piece by piece, and it will be deserved. - Arnaud So, IMHO, not only should it not be enabled by default, but given that it was disabled complete in 8.x after 8.0 (too lazy to look at exactly when right now), I think it shouldn't even be included, since that might encourage users to try it out only to encounter problems with it. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPTD/nAAoJEPXPYrMgexuhvWAH/iPa0N32GJXdyL7OdqFNNuEN R/Z0tOqTCCmAm4WsbAbN3m5poBKNctRtQxG40XoqmvZAWlomwYCwpS2xgCX60NZO XhspUEpQ7cHQpt6ZOW12x3G6FZJ4DzFX0+mDPYxE/7YmwtsjZFeTFGVEPezeKQwr Khar5jWYqETmM1+mFvAFXnfTUiBwnqErDfYmHQAE93wKQd9CyzrFmDfooNTiMUB6 yW+piexN/SzXz6nftQesJbFOWUW6fvhxe9TYcK8+b9zCo2GxPuUrRV60PKQX0apd nlKWtj49znLVzmpTYboQnvmqmk+yik8wL2wszUaZ4jAjieCjWOhJwCWOvkQ9yIg= =SBbK -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
W dniu 2012-02-28 19:55, Arnaud Lacombe pisze: FLOWTABLE on 8.x crashed BGP routers (kern/144917). no crash dump, no backtrace, no follow-up whatsoever after 1 year and 2 years, what's your points ? You could really have chosen a better PR to back up your argument... Sorry, but I don't want to bug trace this issue, simply because lack of time, resources and interest in this feature. I've run into this bug on production box, went through hell because of it and turned off flowtable which I do not use and not need. If this problem is still alive (it might be, the PR I've mentioned is still open) then it's not a good idea to turn on this feature by default. If you're interested in using this feature then feel free to debug and test. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
Hi, 2012/2/28 Łukasz Wąsikowski luk...@wasikowski.net: W dniu 2012-02-28 19:55, Arnaud Lacombe pisze: FLOWTABLE on 8.x crashed BGP routers (kern/144917). no crash dump, no backtrace, no follow-up whatsoever after 1 year and 2 years, what's your points ? You could really have chosen a better PR to back up your argument... Sorry, but I don't want to bug trace this issue, simply because lack of time, resources and interest in this feature. I've run into this bug on production box, went through hell because of it and turned off flowtable which I do not use and not need. If this problem is still alive (it might be, the PR I've mentioned is still open) then it's not a good idea to turn on this feature by default. If you're interested in using this feature then feel free to debug and test. Give me a deterministic way to reproduce the issue and I will. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
W dniu 2012-02-28 22:22, Arnaud Lacombe pisze: FLOWTABLE on 8.x crashed BGP routers (kern/144917). no crash dump, no backtrace, no follow-up whatsoever after 1 year and 2 years, what's your points ? You could really have chosen a better PR to back up your argument... Sorry, but I don't want to bug trace this issue, simply because lack of time, resources and interest in this feature. I've run into this bug on production box, went through hell because of it and turned off flowtable which I do not use and not need. If this problem is still alive (it might be, the PR I've mentioned is still open) then it's not a good idea to turn on this feature by default. If you're interested in using this feature then feel free to debug and test. Give me a deterministic way to reproduce the issue and I will. Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). You need three peers sending you full Internet routing table (3x400k prefixes). Some people got it with only two peers. After a short while your CPU should stuck in 100% busy. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
W dniu 2012-02-28 22:56, Łukasz Wąsikowski pisze: FLOWTABLE on 8.x crashed BGP routers (kern/144917). no crash dump, no backtrace, no follow-up whatsoever after 1 year and 2 years, what's your points ? You could really have chosen a better PR to back up your argument... Sorry, but I don't want to bug trace this issue, simply because lack of time, resources and interest in this feature. I've run into this bug on production box, went through hell because of it and turned off flowtable which I do not use and not need. If this problem is still alive (it might be, the PR I've mentioned is still open) then it's not a good idea to turn on this feature by default. If you're interested in using this feature then feel free to debug and test. Give me a deterministic way to reproduce the issue and I will. Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). You need three peers sending you full Internet routing table (3x400k prefixes). Some people got it with only two peers. After a short while your CPU should stuck in 100% busy. I forgot one thing which may be important. IP addresses used for BGP sessions was heartbeated. So you first need to use those addresses on another box, then move them to flowtable box and run quagga with BGP on it. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On 2/28/2012 10:48 AM, Arnaud Lacombe wrote: You will sure go really far with this kind of It is broken ? Let's not fix it and disable it instead mentality, even more when coming from a committer. As long as there will be these kind of comments around here, FreeBSD will deserve nothing but to keep dying piece by piece, and it will be deserved. In general, I tend to agree with you, but in this case it's useful to know the history of the flowtable option. 1. It was introduced in -current 2. It received fairly good testing, was pronounced good and useful, and MFC'ed. 3. Several releases happened with flowtable. 4. Users started to report problems that were ultimately tracked down to flowtable. 5. Ultimately it was decided that flowtable was not a universal good. 6. The developer of the option agreed that it should be disabled by default until such time as it can be fixed. 7. The fixing hasn't happened yet. While generally fixing things is the right solution, if the fix is complex (or worse, unknown AND complex) then disabling by default is a reasonable answer. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
flowtable usable or not (was: Re: [CFT] modular kernel config
On 28.02.12 23:14, Doug Barton wrote: On 2/28/2012 10:48 AM, Arnaud Lacombe wrote: You will sure go really far with this kind of It is broken ? Let's not fix it and disable it instead mentality, even more when coming from a committer. As long as there will be these kind of comments around here, FreeBSD will deserve nothing but to keep dying piece by piece, and it will be deserved. In general, I tend to agree with you, but in this case it's useful to know the history of the flowtable option. 1. It was introduced in -current 2. It received fairly good testing, was pronounced good and useful, and MFC'ed. 3. Several releases happened with flowtable. 4. Users started to report problems that were ultimately tracked down to flowtable. 5. Ultimately it was decided that flowtable was not a universal good. 6. The developer of the option agreed that it should be disabled by default until such time as it can be fixed. 7. The fixing hasn't happened yet. I talked to Kip Macy, who implemented flowtable, about this. He thinks that the problem was caused by inappropriate default setting of net.inet.ip.output_flowtable_size. This should have been fixed by r205488 which was MFC'd to 8 and should be part of 8.2 and of course 9.0. However nobody who experienced the problem wanted to try any of these releases with flowtable enabled, so we still don't know if it's fixed or not. Should anyone try this it could certainly be the case that net.inet.ip.output_flowtable_size needs to be tuned even more. Florian signature.asc Description: OpenPGP digital signature
Re: [CFT] modular kernel config
W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/12 10:53, Łukasz Wąsikowski wrote: W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. Agree, I've run into problems with FLOWTABLE (with just the features that were enabled by default in 8.0) when routers changed MAC addresses. As far as I understand it, FLOWTABLE is both broken and abandoned (but if I'm wrong, please let me know). So, IMHO, not only should it not be enabled by default, but given that it was disabled complete in 8.x after 8.0 (too lazy to look at exactly when right now), I think it shouldn't even be included, since that might encourage users to try it out only to encounter problems with it. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPTD/nAAoJEPXPYrMgexuhvWAH/iPa0N32GJXdyL7OdqFNNuEN R/Z0tOqTCCmAm4WsbAbN3m5poBKNctRtQxG40XoqmvZAWlomwYCwpS2xgCX60NZO XhspUEpQ7cHQpt6ZOW12x3G6FZJ4DzFX0+mDPYxE/7YmwtsjZFeTFGVEPezeKQwr Khar5jWYqETmM1+mFvAFXnfTUiBwnqErDfYmHQAE93wKQd9CyzrFmDfooNTiMUB6 yW+piexN/SzXz6nftQesJbFOWUW6fvhxe9TYcK8+b9zCo2GxPuUrRV60PKQX0apd nlKWtj49znLVzmpTYboQnvmqmk+yik8wL2wszUaZ4jAjieCjWOhJwCWOvkQ9yIg= =SBbK -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
Quoting Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net (from Wed, 22 Feb 2012 22:31:36 +): On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I only looked at the laoder.conf for amd64 and the only comment I have is that I do not have the time to wait minutes for all individual modules to be loaded. This is going to be really bad for boot time. Well, nobody forces you to use it. And as can be seen on the lists, there are patches floating around to improve the loading speed of the loader. This is also just an example to be on par as much as possible with GENERIC. People which want to use this kernel most probably want to cut the loader.conf down and maybe even want to use the rc.conf setting to load modules which are not needed to boot. The new stuff in the kernel config compared to GENERIC is (in order of number of requests from users): - IPSEC (+ device enc + IPSEC_NAT_T) You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. I planned to contact core to ask if there are some US export restrictions to take into account before committing. Do you have a different hat in mind? - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. I assume this means that the sideeffects are only some conditionals more for the packets which pass the corresponding kernel places (to check if the feature is enabled, I had a look for the IPFIREWALL_FORWARD and IPSTEALTH options regarding this). Regarding the memory usage I assume this means that if someone removes the loading of modules he does not use from the loader.conf, he will use less memory with those things enabled, than would be used by a GENERIC kernel. Both of those things where taken into account before providing this config here. As I wrote above, people which need the last few PPS more can compile a kernel without those features (they are power-users), while people which do not want to compile kernels at all (and there are a lot of such people, just have a look at how many people use freebsd-update and you will get an idea about the target audience) get more features to play with. This is also not supposed to replace GENERIC, but it coud be offered as an option to install this kernel instead of GENERIC (or we can install in in parallel and the user can chose which kernel he wants to boot, or ...). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] modular kernel config
On Thu, Feb 23, 2012 at 09:18:08AM +0100, Alexander Leidinger wrote: Quoting Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net (from Wed, 22 Feb 2012 22:31:36 +): On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I only looked at the laoder.conf for amd64 and the only comment I have is that I do not have the time to wait minutes for all individual modules to be loaded. This is going to be really bad for boot time. Well, nobody forces you to use it. And as can be seen on the lists, there are patches floating around to improve the loading speed of the loader. You can also put most of the modules in rc.conf: kld_list=umass u3g ... That speeds up loading the modules a lot. This is also just an example to be on par as much as possible with GENERIC. People which want to use this kernel most probably want to cut the loader.conf down and maybe even want to use the rc.conf setting to load modules which are not needed to boot. One additional advantage is that you have a bigger chance of a working suspend / resume. Just unload all problematic modules before suspending and re-load them after resuming. pgpRYzgljNwam.pgp Description: PGP signature
Re: [CFT] modular kernel config
On 21. Feb 2012, at 13:35 , Alexander Leidinger wrote: You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I only looked at the laoder.conf for amd64 and the only comment I have is that I do not have the time to wait minutes for all individual modules to be loaded. This is going to be really bad for boot time. The new stuff in the kernel config compared to GENERIC is (in order of number of requests from users): - IPSEC (+ device enc + IPSEC_NAT_T) You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) Which is not the same as it's not 100% disabled and will still allocate memory. -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
