poudriere: Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers.
Hi, I having trouble using poudriere since updating it to 3.0.4 on FreeBSD 9.1-p4. Trying poudriere-devel throws the same error. Here is the complete output of trying to compile shells/bash: # poudriere bulk -p hostportstree -f /usr/local/etc/poudriere.d/91amd64-buildlist.conf -j 91amd64 -J 1 -vv Creating the reference jail... done Mounting system devices for 91amd64-hostportstree Mounting ports/packages/distfiles Mounting packages from: /mnt/system/DATEN/poudriere/basefs/data/packages/91amd64-hostportstree Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options Logs: /mnt/system/DATEN/poudriere/basefs/data/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s WWW: http://pkg.cbt-l.de/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s Appending to make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf - /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/etc/resolv.conf Starting jail 91amd64-hostportstree Calculating ports order and dependencies Computing deps for shells/bash DEBUG: shells/bash depends on ports-mgmt/pkg Computing deps for ports-mgmt/pkg DEBUG: shells/bash depends on devel/bison Computing deps for devel/bison DEBUG: devel/bison depends on ports-mgmt/pkg DEBUG: devel/bison depends on devel/m4 Computing deps for devel/m4 DEBUG: devel/m4 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 Computing deps for lang/perl5.14 DEBUG: lang/perl5.14 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/gettext Computing deps for devel/gettext DEBUG: devel/gettext depends on ports-mgmt/pkg DEBUG: devel/gettext depends on converters/libiconv Computing deps for converters/libiconv DEBUG: converters/libiconv depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/m4 DEBUG: shells/bash depends on devel/gettext DEBUG: shells/bash depends on converters/libiconv pkg package missing, skipping sanity Cleaning the build queue Building 7 packages using 1 builders Starting/Cloning builders mount: linprocfs: File name too long Hit CTRL+t at any time to see build progress and stats [01] Starting build of ports-mgmt/pkg make: chdir /usr/ports/ports-mgmt/pkg: No such file or directory Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers. /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/building /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/9 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/8 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/7 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/6 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/5 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/4 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/2 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/0 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/unbalanced /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/pkg-1.1.4_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/bison-2.7.1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/gettext-0.18.3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/libiconv-1.14_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1/pkg-1.1.4_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1/m4-1.4.16_1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1/perl-5.14.4 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1/gettext-0.18.3 /mnt/system/DATEN/poudriere/basefs/data/build
Re: poudriere: Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers.
On 7/23/2013 8:36 AM, Wolfgang Riegler wrote: Hi, I having trouble using poudriere since updating it to 3.0.4 on FreeBSD 9.1-p4. Trying poudriere-devel throws the same error. Here is the complete output of trying to compile shells/bash: # poudriere bulk -p hostportstree -f /usr/local/etc/poudriere.d/91amd64-buildlist.conf -j 91amd64 -J 1 -vv Creating the reference jail... done Mounting system devices for 91amd64-hostportstree Mounting ports/packages/distfiles Mounting packages from: /mnt/system/DATEN/poudriere/basefs/data/packages/91amd64-hostportstree Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options Logs: /mnt/system/DATEN/poudriere/basefs/data/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s WWW: http://pkg.cbt-l.de/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s Appending to make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf - /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/etc/resolv.conf Starting jail 91amd64-hostportstree Calculating ports order and dependencies Computing deps for shells/bash DEBUG: shells/bash depends on ports-mgmt/pkg Computing deps for ports-mgmt/pkg DEBUG: shells/bash depends on devel/bison Computing deps for devel/bison DEBUG: devel/bison depends on ports-mgmt/pkg DEBUG: devel/bison depends on devel/m4 Computing deps for devel/m4 DEBUG: devel/m4 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 Computing deps for lang/perl5.14 DEBUG: lang/perl5.14 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/gettext Computing deps for devel/gettext DEBUG: devel/gettext depends on ports-mgmt/pkg DEBUG: devel/gettext depends on converters/libiconv Computing deps for converters/libiconv DEBUG: converters/libiconv depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/m4 DEBUG: shells/bash depends on devel/gettext DEBUG: shells/bash depends on converters/libiconv pkg package missing, skipping sanity Cleaning the build queue Building 7 packages using 1 builders Starting/Cloning builders mount: linprocfs: File name too long Hit CTRL+t at any time to see build progress and stats [01] Starting build of ports-mgmt/pkg make: chdir /usr/ports/ports-mgmt/pkg: No such file or directory Does ports-mgmt/pkg exist in the ports tree you are using? Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers. /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/building /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/9 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/8 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/7 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/6 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/5 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/4 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/2 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/0 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/unbalanced /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/pkg-1.1.4_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/bison-2.7.1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/gettext-0.18.3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/libiconv-1.14_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1/pkg-1.1.4_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1/m4-1.4.16_1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison
Re: poudriere: Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers.
yes, there is /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/usr/ports/ports-mgmt/pkg/ regards Wolfgang Am Dienstag, 23. Juli 2013, 08:48:38 schrieb Bryan Drewery: On 7/23/2013 8:36 AM, Wolfgang Riegler wrote: Hi, I having trouble using poudriere since updating it to 3.0.4 on FreeBSD 9.1-p4. Trying poudriere-devel throws the same error. Here is the complete output of trying to compile shells/bash: # poudriere bulk -p hostportstree -f /usr/local/etc/poudriere.d/91amd64-buildlist.conf -j 91amd64 -J 1 -vv Creating the reference jail... done Mounting system devices for 91amd64-hostportstree Mounting ports/packages/distfiles Mounting packages from: /mnt/system/DATEN/poudriere/basefs/data/packages/91amd64-hostportstree Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options Logs: /mnt/system/DATEN/poudriere/basefs/data/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s WWW: http://pkg.cbt-l.de/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s Appending to make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf - /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/etc/resolv.conf Starting jail 91amd64-hostportstree Calculating ports order and dependencies Computing deps for shells/bash DEBUG: shells/bash depends on ports-mgmt/pkg Computing deps for ports-mgmt/pkg DEBUG: shells/bash depends on devel/bison Computing deps for devel/bison DEBUG: devel/bison depends on ports-mgmt/pkg DEBUG: devel/bison depends on devel/m4 Computing deps for devel/m4 DEBUG: devel/m4 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 Computing deps for lang/perl5.14 DEBUG: lang/perl5.14 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/gettext Computing deps for devel/gettext DEBUG: devel/gettext depends on ports-mgmt/pkg DEBUG: devel/gettext depends on converters/libiconv Computing deps for converters/libiconv DEBUG: converters/libiconv depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/m4 DEBUG: shells/bash depends on devel/gettext DEBUG: shells/bash depends on converters/libiconv pkg package missing, skipping sanity Cleaning the build queue Building 7 packages using 1 builders Starting/Cloning builders mount: linprocfs: File name too long Hit CTRL+t at any time to see build progress and stats [01] Starting build of ports-mgmt/pkg make: chdir /usr/ports/ports-mgmt/pkg: No such file or directory Does ports-mgmt/pkg exist in the ports tree you are using? Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers. /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/building /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/9 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/8 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/7 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/6 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/5 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/4 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/2 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/0 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/unbalanced /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/pkg-1.1.4_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/bison-2.7.1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/gettext-0.18.3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/libiconv-1.14_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1 /mnt/system/DATEN/poudriere/basefs/data/build
Re: poudriere: Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers.
On 7/23/2013 9:00 AM, Wolfgang Riegler wrote: yes, there is /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/usr/ports/ports-mgmt/pkg/ Can you try with NOLINUX=yes in your poudriere.conf? regards Wolfgang Am Dienstag, 23. Juli 2013, 08:48:38 schrieb Bryan Drewery: On 7/23/2013 8:36 AM, Wolfgang Riegler wrote: Hi, I having trouble using poudriere since updating it to 3.0.4 on FreeBSD 9.1-p4. Trying poudriere-devel throws the same error. Here is the complete output of trying to compile shells/bash: # poudriere bulk -p hostportstree -f /usr/local/etc/poudriere.d/91amd64-buildlist.conf -j 91amd64 -J 1 -vv Creating the reference jail... done Mounting system devices for 91amd64-hostportstree Mounting ports/packages/distfiles Mounting packages from: /mnt/system/DATEN/poudriere/basefs/data/packages/91amd64-hostportstree Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options Logs: /mnt/system/DATEN/poudriere/basefs/data/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s WWW: http://pkg.cbt-l.de/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s Appending to make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf - /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/etc/resolv.conf Starting jail 91amd64-hostportstree Calculating ports order and dependencies Computing deps for shells/bash DEBUG: shells/bash depends on ports-mgmt/pkg Computing deps for ports-mgmt/pkg DEBUG: shells/bash depends on devel/bison Computing deps for devel/bison DEBUG: devel/bison depends on ports-mgmt/pkg DEBUG: devel/bison depends on devel/m4 Computing deps for devel/m4 DEBUG: devel/m4 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 Computing deps for lang/perl5.14 DEBUG: lang/perl5.14 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/gettext Computing deps for devel/gettext DEBUG: devel/gettext depends on ports-mgmt/pkg DEBUG: devel/gettext depends on converters/libiconv Computing deps for converters/libiconv DEBUG: converters/libiconv depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/m4 DEBUG: shells/bash depends on devel/gettext DEBUG: shells/bash depends on converters/libiconv pkg package missing, skipping sanity Cleaning the build queue Building 7 packages using 1 builders Starting/Cloning builders mount: linprocfs: File name too long Hit CTRL+t at any time to see build progress and stats [01] Starting build of ports-mgmt/pkg make: chdir /usr/ports/ports-mgmt/pkg: No such file or directory Does ports-mgmt/pkg exist in the ports tree you are using? Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers. /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/building /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/9 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/8 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/7 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/6 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/5 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/4 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/2 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/0 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/unbalanced /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/pkg-1.1.4_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/bison-2.7.1,1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/gettext-0.18.3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/libiconv-1.14_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bison-2.7.1,1 /mnt/system/DATEN
Re: poudriere: Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers.
Running poudriere with NO_LINUX=yes in poudriere.conf seems to work. Because I using FreeBSD as a desktop system as well. I need some linux ports. Any chance for it? thanks regards Wolfgang Am Dienstag, 23. Juli 2013, 09:12:13 schrieb Bryan Drewery: On 7/23/2013 9:00 AM, Wolfgang Riegler wrote: yes, there is /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/usr/ports/ports-mgmt/pkg/ Can you try with NOLINUX=yes in your poudriere.conf? regards Wolfgang Am Dienstag, 23. Juli 2013, 08:48:38 schrieb Bryan Drewery: On 7/23/2013 8:36 AM, Wolfgang Riegler wrote: Hi, I having trouble using poudriere since updating it to 3.0.4 on FreeBSD 9.1-p4. Trying poudriere-devel throws the same error. Here is the complete output of trying to compile shells/bash: # poudriere bulk -p hostportstree -f /usr/local/etc/poudriere.d/91amd64-buildlist.conf -j 91amd64 -J 1 -vv Creating the reference jail... done Mounting system devices for 91amd64-hostportstree Mounting ports/packages/distfiles Mounting packages from: /mnt/system/DATEN/poudriere/basefs/data/packages/91amd64-hostportstree Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options Logs: /mnt/system/DATEN/poudriere/basefs/data/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s WWW: http://pkg.cbt-l.de/logs/bulk/91amd64-hostportstree/2013-07-23_14h06m33s Appending to make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf - /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/etc/resolv.conf Starting jail 91amd64-hostportstree Calculating ports order and dependencies Computing deps for shells/bash DEBUG: shells/bash depends on ports-mgmt/pkg Computing deps for ports-mgmt/pkg DEBUG: shells/bash depends on devel/bison Computing deps for devel/bison DEBUG: devel/bison depends on ports-mgmt/pkg DEBUG: devel/bison depends on devel/m4 Computing deps for devel/m4 DEBUG: devel/m4 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 Computing deps for lang/perl5.14 DEBUG: lang/perl5.14 depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/gettext Computing deps for devel/gettext DEBUG: devel/gettext depends on ports-mgmt/pkg DEBUG: devel/gettext depends on converters/libiconv Computing deps for converters/libiconv DEBUG: converters/libiconv depends on ports-mgmt/pkg DEBUG: devel/bison depends on lang/perl5.14 DEBUG: devel/bison depends on devel/m4 DEBUG: shells/bash depends on devel/gettext DEBUG: shells/bash depends on converters/libiconv pkg package missing, skipping sanity Cleaning the build queue Building 7 packages using 1 builders Starting/Cloning builders mount: linprocfs: File name too long Hit CTRL+t at any time to see build progress and stats [01] Starting build of ports-mgmt/pkg make: chdir /usr/ports/ports-mgmt/pkg: No such file or directory Does ports-mgmt/pkg exist in the ports tree you are using? Error: Unknown stuck queue bug detected. Please submit the entire build output to poudriere developers. /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/building /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/9 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/8 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/7 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/6 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/5 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/4 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/3 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/2 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/0 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/pool/unbalanced /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/pkg-1.1.4_1 /mnt/system/DATEN/poudriere/basefs/data/build/91amd64-hostportstree/ref/poudriere/deps/bash-4.2.45/bison-2.7.1,1 /mnt
Bug or feature - arp command on vlan in 9.0
Hi, I have about 120 FBSD routers - diskless. I use FBSD 8.2, with no problems. But now I am trying 9.0, the same configuration I found difference of behavior command arp between 8.2 and 9.0. In 8.2 I can see arp of ip on all devices, physical and vlans. vlan356: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=3RXCSUM,TXCSUM inet 10.201.15.65 netmask 0xffe0 broadcast 10.201.15.95 %arp 10.201.15.65 ? (10.201.15.65) at 00:25:90:50:29:82 on vlan356 permanent [vlan] On 9.0 i can see arp only on physical interface em0, on vlans no: vlan319: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=3RXCSUM,TXCSUM inet 10.219.5.193 netmask 0xffe0 broadcast 10.219.5.223 %ping 10.219.5.193 PING 10.219.5.193 (10.219.5.193): 56 data bytes 64 bytes from 10.219.5.193: icmp_seq=0 ttl=64 time=0.032 ms ^C --- 10.219.5.193 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.032/0.032/0.032/0.000 ms %arp 10.219.5.193 10.219.5.193 (10.219.5.193) -- no entry Is it bug or feature? Thanks Radek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Xiphos Locale Bug?
FreeBSD 9.0-RELEASE, i386 Xiphos is giving me a strange warning[0], and I'm not quite sure what to make of it. The forums don't address this specifically that I could find, and nothing via a web search seemed to be relevant to my issue. Not quite sure what the issue is, either, to be honest. I did recently set in /etc/login.conf (and made sure the update made it to ~/.login_conf): # # American Users Accounts. Setup proper environment variables. # american|American Users Accounts:\ :charset=iso-8859-1:\ :lang=en_US.iso-8859-1:\ :tc=default: Basically I copied the Russian settings (and then commented them out, not sure why they are uncommented by default), replacing the lang and charset as appropriate (I don't care how many of you like UTF-8, either, keep it to yourselves). Should I just re-compile now that I've explicitly set things? I couldn't find anything in the misc/xiphos/Makefile to manually change it and am assuming it takes that from the environment? I found a thread[1] in the forums that gave me the idea for the above block [0]: http://www.joseph-a-nagy-jr.us/images/problems/xiphos.png [1]: http://forums.freebsd.org/showthread.php?t=9120 -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.org signature.asc Description: OpenPGP digital signature
Re: Xiphos Locale Bug?
On Mon, 05 Nov 2012 18:54:43 -0600, Joseph a Nagy Jr wrote: FreeBSD 9.0-RELEASE, i386 Xiphos is giving me a strange warning[0], and I'm not quite sure what to make of it. Currently C is set as the default language setting (locale) for that specific program. It cannot handle it and probably won't (as indicated) translate things properly. C is the typical fallback locale. See the settings of $LANG and the $LC_* variables. There is a specific precedence in their evaluation! # # American Users Accounts. Setup proper environment variables. # american|American Users Accounts:\ :charset=iso-8859-1:\ :lang=en_US.iso-8859-1:\ :tc=default: Basically I copied the Russian settings (and then commented them out, not sure why they are uncommented by default), replacing the lang and charset as appropriate (I don't care how many of you like UTF-8, either, keep it to yourselves). Looks fully valid. Should I just re-compile now that I've explicitly set things? Why? Language settings are evaluated at runtime, no need to compile anything. As you have made the change to login.conf (at the global level), make sure your user account doesn't override anything. Also check if you need to run cap_mkdb to create login.conf.db from your settings. Alternatively (usually not recommended, but works) you can set (i. e. setenv) language variables in /etc/csh.cshrc globally, or ~/.cshrc for your user account. Example: setenv LC_ALL en_US.ISO8859-1 setenv LC_MESSAGES en_US.ISO8859-1 setenv LC_COLLATE de_DE.ISO8859-1 setenv LC_CTYPEde_DE.ISO8859-1 setenv LC_MONETARY de_DE.ISO8859-1 setenv LC_NUMERIC de_DE.ISO8859-1 setenv LC_TIME de_DE.ISO8859-1 unsetenv LANG That will leave english text intact (most usable language setting for most programs), but allow specific settings like time notation or collation according to the german rules. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Xiphos Locale Bug?
On 11/05/12 19:19, Polytropon wrote: On Mon, 05 Nov 2012 18:54:43 -0600, Joseph a Nagy Jr wrote: FreeBSD 9.0-RELEASE, i386 Xiphos is giving me a strange warning[0], and I'm not quite sure what to make of it. Currently C is set as the default language setting (locale) for that specific program. It cannot handle it and probably won't (as indicated) translate things properly. C is the typical fallback locale. Really? Seems a bit odd. See the settings of $LANG and the $LC_* variables. There is a specific precedence in their evaluation! Ah, I will have to read up on those, for future reference. # # American Users Accounts. Setup proper environment variables. # american|American Users Accounts:\ :charset=iso-8859-1:\ :lang=en_US.iso-8859-1:\ :tc=default: Basically I copied the Russian settings (and then commented them out, not sure why they are uncommented by default), replacing the lang and charset as appropriate (I don't care how many of you like UTF-8, either, keep it to yourselves). Looks fully valid. Good. Should I just re-compile now that I've explicitly set things? Why? Language settings are evaluated at runtime, no need to compile anything. As you have made the change to login.conf (at the global level), make sure your user account doesn't override anything. Also check if you need to run cap_mkdb to create login.conf.db from your settings. I already ran it, I just need to logout/in after LibreOffice is done compiling. Alternatively (usually not recommended, but works) you can set (i. e. setenv) language variables in /etc/csh.cshrc globally, or ~/.cshrc for your user account. Example: setenv LC_ALL en_US.ISO8859-1 setenv LC_MESSAGES en_US.ISO8859-1 setenv LC_COLLATE de_DE.ISO8859-1 setenv LC_CTYPEde_DE.ISO8859-1 setenv LC_MONETARY de_DE.ISO8859-1 setenv LC_NUMERIC de_DE.ISO8859-1 setenv LC_TIME de_DE.ISO8859-1 unsetenv LANG That will leave english text intact (most usable language setting for most programs), but allow specific settings like time notation or collation according to the german rules. Will keep that in mind for future reference. I'm going to be learning one or two new languages soon and that will be helpful when I go to set up a new user to practice reading (and not just talking) those languages. (: -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.org signature.asc Description: OpenPGP digital signature
Re: Xiphos Locale Bug?
On Mon, 05 Nov 2012 19:25:54 -0600, Joseph a Nagy Jr wrote: On 11/05/12 19:19, Polytropon wrote: On Mon, 05 Nov 2012 18:54:43 -0600, Joseph a Nagy Jr wrote: FreeBSD 9.0-RELEASE, i386 Xiphos is giving me a strange warning[0], and I'm not quite sure what to make of it. Currently C is set as the default language setting (locale) for that specific program. It cannot handle it and probably won't (as indicated) translate things properly. C is the typical fallback locale. Really? Seems a bit odd. No, it's just the most simple setting. :-) It is what e. g. functions listed in man 3 ctype will refer to. See the settings of $LANG and the $LC_* variables. There is a specific precedence in their evaluation! Ah, I will have to read up on those, for future reference. From man csh: When using the system's NLS, the setlocale(3) function is called to determine appropriate character code/classification and sorting (e.g., a 'en_CA.UTF-8' would yield UTF-8 as a character code). This func- tion typically examines the LANG and LC_CTYPE environment variables; refer to the system documentation for further details. When not using the system's NLS, the shell simulates it by assuming that the ISO 8859-1 character set is used whenever either of the LANG and LC_CTYPE variables are set, regardless of their values. Sorting is not affected for the simulated NLS. You can find the meaning of the $LC_* variables in man 3 setlocale for reference. They allow a fine grained specification of what should be dealt with in which language, while $LANG is easier to use for one size fits all requirements. Should I just re-compile now that I've explicitly set things? Why? Language settings are evaluated at runtime, no need to compile anything. As you have made the change to login.conf (at the global level), make sure your user account doesn't override anything. Also check if you need to run cap_mkdb to create login.conf.db from your settings. I already ran it, I just need to logout/in after LibreOffice is done compiling. You can temporarily call a program with a different setting to see what language it runs in: $ LC_ALL=de_DE.ISO8859-1 /usr/local/bin/mc $ LC_ALL=pl_PL.ISO8859-2 /usr/local/bin/mc $ LC_ALL=en_US.ISO8859-1 /usr/local/bin/mc This will of course only work for _that_ specific program call and will not persist. Using UTF-8 instead of one of the ISO encodings could lead to screen character garbage. :-) Alternatively (usually not recommended, but works) you can set (i. e. setenv) language variables in /etc/csh.cshrc globally, or ~/.cshrc for your user account. Example: setenv LC_ALL en_US.ISO8859-1 setenv LC_MESSAGES en_US.ISO8859-1 setenv LC_COLLATE de_DE.ISO8859-1 setenv LC_CTYPEde_DE.ISO8859-1 setenv LC_MONETARY de_DE.ISO8859-1 setenv LC_NUMERIC de_DE.ISO8859-1 setenv LC_TIME de_DE.ISO8859-1 unsetenv LANG That will leave english text intact (most usable language setting for most programs), but allow specific settings like time notation or collation according to the german rules. Will keep that in mind for future reference. I'm going to be learning one or two new languages soon and that will be helpful when I go to set up a new user to practice reading (and not just talking) those languages. (: I went with the above approach to have all my programs talk in english because they are easier to understand than the only partially done and sloppy german translations. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[SOLVED]Re: Xiphos Locale Bug?
snip Thanks for the help and quick lessons! Very useful information to know! -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://owl.apotheon.org signature.asc Description: OpenPGP digital signature
Bug in LAGG driver at 9.0 ?
Hello I cannot get the lagg driver to work properly at 9.0 the Cisco switch is well configured to support LACP no problem on that side it supports another Linux server with two aggregated eth ports that works well. here is the config of the FreeBSD 9.0-P3 server ifconfig_bce0=up ifconfig_bce1=up ifconfig_bce2=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport bce0 laggport bce1 laggport bce2 ipv4_addrs_lagg0=147.215.201.21/24 defaultrouter=147.215.201.1 showing the lagg configuration give the following , only one ethernet port is active. ifconfig lagg0 lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 00:9c:02:9a:97:b0 inet 147.215.201.21 netmask 0xff00 broadcast 147.215.201.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: active laggproto lacp laggport: bce2 flags=0 laggport: bce1 flags=0 laggport: bce0 flags=1cACTIVE,COLLECTING,DISTRIBUTING Thanks for any info/idea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bug in LAGG driver at 9.0 ?
On 2012-10-23 06:02, Frank Bonnet wrote: Hello I cannot get the lagg driver to work properly at 9.0 the Cisco switch is well configured to support LACP no problem on that side it supports another Linux server with two aggregated eth ports that works well. here is the config of the FreeBSD 9.0-P3 server ifconfig_bce0=up ifconfig_bce1=up ifconfig_bce2=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport bce0 laggport bce1 laggport bce2 ipv4_addrs_lagg0=147.215.201.21/24 defaultrouter=147.215.201.1 showing the lagg configuration give the following , only one ethernet port is active. ifconfig lagg0 lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 00:9c:02:9a:97:b0 inet 147.215.201.21 netmask 0xff00 broadcast 147.215.201.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: active laggproto lacp laggport: bce2 flags=0 laggport: bce1 flags=0 laggport: bce0 flags=1cACTIVE,COLLECTING,DISTRIBUTING Thanks for any info/idea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Can you post your Cisco Switch port configuration? I have a two port LAGG using lacp on two separate Dell PowerEdge servers running 9.0-RELEASEp3, below is my config in FreeBSD the only differences I see apart form 2 instead of three ports, is that I named the interface, and used a different syntax to specify the ip addresses, but yours should be correct as well. uname -v FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 26 10:27:21 CDT 2012 ifconfig_bce0=up ifconfig_bce1=up cloned_interfaces=lagg6 ifconfig_lagg6_name=DMZ ifconfig_DMZ=laggproto lacp laggport bce0 laggport bce1 ifconfig_DMZ_alias0=inet 10.50.20.5 netmask 0x ifconfig_DMZ_alias1=inet 10.52.20.5 netmask 0x defaultrouter=10.50.110.4 DMZ: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 78:2b:cb:68:9f:1e inet 10.50.20.5 netmask 0x broadcast 10.50.255.255 inet 10.52.20.5 netmask 0x broadcast 10.52.255.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: active laggproto lacp laggport: bce1 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: bce0 flags=1cACTIVE,COLLECTING,DISTRIBUTING -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Bug in LAGG driver at 9.0 P3 ?
Hello I have a problem with a server running FreeBSD 9.0-P3 It seems the lagg driver does not works well here is the contents of the /etc/rc.conf file the problem is, only the first interface (bce0) is working in the lagg0 interface , the two others are not active ifconfig_bce0=up ifconfig_bce1=up ifconfig_bce2=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport bce0 laggport bce1 laggport bce2 ipv4_addrs_lagg0=147.215.201.21/24 defaultrouter=147.215.201.1 here is the result of the ifconfig lagg0 command : primail# ifconfig lagg0 lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 00:9c:02:9a:97:b0 inet 147.215.201.21 netmask 0xff00 broadcast 147.215.201.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: active laggproto lacp laggport: bce2 flags=0 laggport: bce1 flags=0 laggport: bce0 flags=1cACTIVE,COLLECTING,DISTRIBUTING thanks for any info/idea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: ZFS sharenfs problem - bug?
Hi again, I take example line from manual: zfs set sharenfs='rw=@123.123.0.0/16,root=neo' tank/home modify it to: zfs set sharenfs='rw=@pokus.starnet.cz,root=0' storage/pokus and I got in messagess Aug 16 12:04:45 storage mountd[1180]: can't get address info for host rw=@pokus.starnet.cz Aug 16 12:04:45 storage mountd[1180]: bad host rw=@pokus.starnet.cz, skipping Aug 16 12:04:45 storage mountd[1180]: can't get address info for host root=0 Aug 16 12:04:45 storage mountd[1180]: bad host root=0, skipping Aug 16 12:04:45 storage mountd[1180]: bad exports list line /usr/local/storage/pokus rw=@pokus.starnet.cz root=0 my /etc/zfs/exports # !!! DO NOT EDIT THIS FILE MANUALLY !!! /usr/local/storage/pokus rw=@pokus.starnet.cz root=0 . pokus.starnet.cz is in dns (reversible dns too), if I use IP address, the situation is the same. zfs get shows: storage/pokus sharenfs rw=@pokus.starnet.cz,root=0 local storage/pokus version 5 - uname: FreeBSD storage.starnet.cz 9.0-RELEASE-p4 FreeBSD 9.0-RELEASE-p4 #2: Sat Aug 11 17:48:50 CEST 2012 r...@storage.starnet.cz:/usr/obj/usr/src/sys/GENERIC amd64 Where could be a problem? Is it bug or I am wrong but I dont see any mistake Thank you Radek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: ZFS sharenfs problem - solved, documentation bug
Hi again, I take example line from manual: zfs set sharenfs='rw=@123.123.0.0/16,root=neo' tank/home modify it to: zfs set sharenfs='rw=@pokus.starnet.cz,root=0' storage/pokus Where could be a problem? Is it bug or I am wrong but I dont see any mistake I found solution finally on the web (and I lost week with finding solution :-(() zfs sharenfs=-maproot=0:0 pokus.starnet.cz storage/pokus This command works but there is mistake in documentation... Radek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
bug in /usr/bin/calendar: Thu+1 doesn't match on 7th or December
Bug report for /usr/bin/calendar SUMMARY: calendar does not match Thu+1 or Mon+1 in some months. With one exception, it looks like calendar file dates such as Thu+1 and Mon+1 are failing to match in two cases: (1) the 7th of Jan-Nov, and (2) December. DETAILS/EXAMPLES: FreeBSD crystal 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 The bug occurs whether or not the command line options below are used. I first noticed it today (a Wednesday) because a Thu+1 event tomorrow was not in calendar's output. Example 1: Thu+1 ~/.calendar/calendar: Thu+1 foo (that's Thu+1\tfoo\n in C) foreach i ( 1 2 3 4 5 6 7 8 9 10 11 12 ) calendar -t 1.$i.2011 -W 9 end Jan 6* foo Feb 3* foo Mar 3* foo - Apr 7 absent May 5* foo Jun 2* foo - Jul 7 absent Aug 4* foo Sep 1* foo Oct 6* foo Nov 3* foo - Dec 1 absent foreach i ( 1 2 3 4 5 6 7 8 9 10 11 12 ) calendar -t 1.$i.2012 -W 9 end Jan 5* foo Feb 2* foo Mar 1* foo Apr 5* foo May 3* foo - Jun 7 absent Jul 5* foo Aug 2* foo Sep 6* foo Oct 4* foo Nov 1* foo - Dec 6 absent foreach i ( 1 2 3 4 5 6 7 8 9 10 11 12 ) calendar -t 1.$i.2013 -W 9 end Jan 3* foo - Feb 7 absent - Mar 7 absent Apr 4* foo May 2* foo Jun 6* foo Jul 4* foo Aug 1* foo Sep 5* foo Oct 3* foo - Nov 7 absent - Dec 5 absent Example 2: Mon+1 foo: Mon+1 foo (Mon+1\tfoo\n) foreach i ( 1 2 3 4 5 6 7 8 9 10 11 12 ) calendar -t 1.$i.2011 -W 9 -f foo end Jan 3* foo - Feb 7 absent - Mar 7 absent Apr 4* foo May 2* foo Jun 6* foo Jul 4* foo Aug 1* foo Sep 5* foo Oct 3* foo - Nov 7 absent - Dec 5 absent foreach i ( 1 2 3 4 5 6 7 8 9 10 11 12 ) calendar -t 1.$i.2012 -W 9 -f foo end Jan 2* foo Feb 6* foo Mar 5* foo Apr 2* foo - May 3 absent --- EXCEPTION! Jun 4* foo Jul 2* foo Aug 6* foo Sep 3* foo Oct 1* foo Nov 5* foo - Dec 3 absent foreach i ( 1 2 3 4 5 6 7 8 9 10 11 12 ) calendar -t 1.$i.2013 -W 9 -f foo end - Jan 7 absent Feb 4* foo Mar 4* foo Apr 1* foo May 6* foo Jun 3* foo Jul 1* foo Aug 5* foo Sep 2* foo - Oct 7 absent Nov 4* foo - Dec 2 absent HTH, -WBE ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: bug in /usr/bin/calendar: Thu+1 doesn't match on 7th or December
Hi, Please report bugs with send-pr (cos bug reports to mail list get lost) See man send-pr If you can attach a patch to fix it, so much the better Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Possible /bin/sh Bug?
Given this script: #!/bin/sh foo= while read line do foo=$foo -e done echo $foo Say I respond 3 times, I'd expect to see: -e -e -e Instead, I get: -e -e Linux appears to do the right thing here, so this seems like it is a bug ... or am I missing something? -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Possible /bin/sh Bug?
In the last episode (Jun 05), Tim Daneliuk said: Given this script: #!/bin/sh foo= while read line do foo=$foo -e done echo $foo Say I respond 3 times, I'd expect to see: -e -e -e Instead, I get: -e -e Linux appears to do the right thing here, so this seems like it is a bug ... or am I missing something? echo takes a -e flag, so it eats the first one. Bash does the same thing, so any Linux that uses bash as /bin/sh will also. You must be testing on a Linux that uses something else as /bin/sh. Better to use the printf command if you are worried about compatibility. echo [-e | -n] [string ...] Print a space-separated list of the arguments to the standard output and append a newline character. -n Suppress the output of the trailing newline. -e Process C-style backslash escape sequences. The echo command understands the following character escapes: -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Possible /bin/sh Bug?
On 06/05/2012 11:35 AM, Dan Nelson wrote: In the last episode (Jun 05), Tim Daneliuk said: Given this script: #!/bin/sh foo= while read line do foo=$foo -e done echo $foo Say I respond 3 times, I'd expect to see: -e -e -e Instead, I get: -e -e Linux appears to do the right thing here, so this seems like it is a bug ... or am I missing something? echo takes a -e flag, so it eats the first one. Bash does the same thing, so any Linux that uses bash as /bin/sh will also. You must be testing on a Linux that uses something else as /bin/sh. Better to use the printf command if you are worried about compatibility. echo [-e | -n] [string ...] Print a space-separated list of the arguments to the standard output and append a newline character. -n Suppress the output of the trailing newline. -e Process C-style backslash escape sequences. The echo command understands the following character escapes: Ah, OK, that makes sense, thanks... -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Possible /bin/sh Bug?
On Tue, 05 Jun 2012 10:40:45 -0500 Tim Daneliuk tun...@tundraware.com wrote: Given this script: #!/bin/sh foo= while read line do foo=$foo -e done echo $foo Say I respond 3 times, I'd expect to see: -e -e -e Instead, I get: -e -e The last line echo $foo is what is getting confused. At the end of 3 passes, $foo contains -e -e -e so when the last line is executed, it looks like: echo -e -e -e The first -e is probably being interperted by echo as a flag ( echo -e ) and then only prints the last two -e. Its easier to see if you execute the script with xtrace: sh -x /path/to/script I'd recommend that you write the last line with quotes: echo $foo and I think it'll produce the results you expect. HTH, Randy ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Possible /bin/sh Bug?
From: Tim Daneliuk tun...@tundraware.com Given this script: #!/bin/sh foo= while read line do foo=$foo -e done echo $foo Say I respond 3 times, I'd expect to see: -e -e -e Instead, I get: -e -e Linux appears to do the right thing here, so this seems like it is a bug ... or am I missing something? Yup. there are -multiple-, incompatible, standards for 'echo'. a SYS-V derived echo will behve diferently than UCB based one. varous shell-program 'built-in' implementtions may have yet different behavior. Recommendation -- use 'print' instead of 'echo', it is much more predictble in differnt environments. ALTERNATIVE: replace the last line of the script with: echo -- $foo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Xorg bug or better Xorg file problems
Hello first of all. This is my first post here.. a test.. i stream on line as i read todays post. So about xorg file cause i make 6 months with nvidia 9200fx let talk first for the card. second there is no xorg need it so u can back up and delete it, and test you X with xrandr -q man xrandr and more. The last think that comes in my mind cause doug speaks for flashing is the DFP screen maybe need and edid.bin file into you etx/X11 ofcaurce search forums data for xorg confg option. Thank you. and Hello there -- My webpages egelor http://egelor.tumblr.com : egepresshttp://egepress.wordpress.com : My Server Actapus http://egelor.dyndns.org Piece Love Unity_ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Xorg bug
This is 9.0-RELEASE with all else installed via pkg_add. Xorg is 7.5.1; xdm is 1.1.11. When logging out or terminating Xorg the screen flashes a line that is the login pattern at the top of the screen. The rest of the screen is black. ctrl-alt-F1 switches to the console but the monitor is disconnected (e.g., I eventually get 'no signal' as if the system is powered down). ctrl-alt-F9 returns to the xdm login which then works normally. I am using xfce and see no problems after logging. There are no errors logged in .xsession-errors, Xorg.0.log or xdm.log. I get the same symptoms with and without hal and when Xorg is started with startx or startxfce4. xorg.conf is unmodified from a 'Xorg -configure'. The monitor driver select is radeon. The radeonhd driver crashes. The system is not down, as I can ssh into it,the only real bug is that the consoles are not available. I think this is a bug handling the monitor rather than the keyboard because of the 'no signal' indication and the ctrl-alt keys work, I just can not see whats on the console. Is additional logging available? Anybody seen one like this? _ Douglas Denault http://www.safeport.com d...@safeport.com Voice: 301-217-9220 Fax: 301-217-9277 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Xorg bug
On Apr 6, 2012 10:40 AM, d...@safeport.com wrote: This is 9.0-RELEASE with all else installed via pkg_add. Xorg is 7.5.1; xdm is 1.1.11. When logging out or terminating Xorg the screen flashes a line that is the login pattern at the top of the screen. The rest of the screen is black. ctrl-alt-F1 switches to the console but the monitor is disconnected (e.g., I eventually get 'no signal' as if the system is powered down). ctrl-alt-F9 returns to the xdm login which then works normally. I am using xfce and see no problems after logging. There are no errors logged in .xsession-errors, Xorg.0.log or xdm.log. I get the same symptoms with and without hal and when Xorg is started with startx or startxfce4. xorg.conf is unmodified from a 'Xorg -configure'. The monitor driver select is radeon. The radeonhd driver crashes. The system is not down, as I can ssh into it,the only real bug is that the consoles are not available. I think this is a bug handling the monitor rather than the keyboard because of the 'no signal' indication and the ctrl-alt keys work, I just can not see whats on the console. Is additional logging available? Anybody seen one like this? _ Douglas Denault http://www.safeport.com d...@safeport.com Voice: 301-217-9220 Fax: 301-217-9277 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Hi, On my amd64 machine running 10.0-CURRENT with xfce4 the screen turns white when i logout or use the shutdown button. i'm running the latest in packages, will have to check the version. ssh into machine still works except that within 40 seconds or so the machine freezes. my work-around is to do shutdown -r now from terminal, which shuts down before 40 seconds :) shutdown without r does not stop it from freezing. i have not yet taken the time to troubleshoot but maybe this weekend ill get the details together and try to see what the problem is. Waitman Gobble San Jose California USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Xorg bug
On Fri, 6 Apr 2012, Waitman Gobble wrote: On Apr 6, 2012 10:40 AM, d...@safeport.com wrote: This is 9.0-RELEASE with all else installed via pkg_add. Xorg is 7.5.1; xdm is 1.1.11. When logging out or terminating Xorg the screen flashes a line that is the login pattern at the top of the screen. The rest of the screen is black. ctrl-alt-F1 switches to the console but the monitor is disconnected (e.g., I eventually get 'no signal' as if the system is powered down). ctrl-alt-F9 returns to the xdm login which then works normally. I am using xfce and see no problems after logging. There are no errors logged in .xsession-errors, Xorg.0.log or xdm.log. I get the same symptoms with and without hal and when Xorg is started with startx or startxfce4. xorg.conf is unmodified from a 'Xorg -configure'. The monitor driver select is radeon. The radeonhd driver crashes. The system is not down, as I can ssh into it,the only real bug is that the consoles are not available. I think this is a bug handling the monitor rather than the keyboard because of the 'no signal' indication and the ctrl-alt keys work, I just can not see whats on the console. Is additional logging available? Anybody seen one like this? Hi, On my amd64 machine running 10.0-CURRENT with xfce4 the screen turns white when i logout or use the shutdown button. i'm running the latest in packages, will have to check the version. ssh into machine still works except that within 40 seconds or so the machine freezes. my work-around is to do shutdown -r now from terminal, which shuts down before 40 seconds :) shutdown without r does not stop it from freezing. i have not yet taken the time to troubleshoot but maybe this weekend ill get the details together and try to see what the problem is. Thanks. AFAIK my system does not freeze but I do not know that I have waited it out either. I will let you know with a list-only post. _ Douglas Denault http://www.safeport.com d...@safeport.com Voice: 301-217-9220 Fax: 301-217-9277___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LAGG bug or misconfiguration???
Hi guys ... just for the record. I've fixed the issue simply moving the cable of the backup interface to another switch as suggested by the network guys of the DC. Which is even preferable under the network redundancy perspective. Now works perfectly and the failover NIC0-NIC1 and (NIC1-NIC0) is immediate. Many thanks for your time. Cheers. On Fri, 2012-03-16 at 17:49 +0100, Damien Fleuriot wrote: I confirm you should see fast transition for your VLANs to forwarding state. Are your ports in access or trunk mode ? If they're trunked, portfast alone won't do it, you need spanning-tree portfast trunk. Additionally, are you using link aggregation on the cisco swi ? (channel-group) On 3/16/12 5:31 PM, Snoop wrote: That's the STP configuration on my two switch ports: spanning-tree portfast spanning-tree bpduguard enable On Fri, 2012-03-16 at 12:10 +0100, Damien Fleuriot wrote: You're not looking for FEC or ethechannel or 802.3ad at all. What you're looking for, in the case of a *failover* configuration, is a spanning-tree portfast feature so that your port doesn't transition through the different spantree states before forwarding traffic. Kindly obtain the configuration from whoever has it and let us know. On 3/16/12 11:18 AM, Snoop wrote: Hi Dweimer and Damien, thanks for replying. The server is connected to a switch of the datacentre. The configuration of this switch is unknown to me and I obviously have no access to it but I truly believe that such an enterprise environment has management capabilities. Anyway, in which way the configuration would affect the lagg functionality? Might this issue be related to what stated in the FreeBSD LAGG pages in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Cisco® Fast EtherChannel® Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. If the switch supports LACP then that should be used instead. On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover
Re: LAGG bug or misconfiguration???
Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=4ACTIVE laggport: bge0 flags=1MASTER ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE __ Also nothing unusual
Re: LAGG bug or misconfiguration???
Hi Dweimer and Damien, thanks for replying. The server is connected to a switch of the datacentre. The configuration of this switch is unknown to me and I obviously have no access to it but I truly believe that such an enterprise environment has management capabilities. Anyway, in which way the configuration would affect the lagg functionality? Might this issue be related to what stated in the FreeBSD LAGG pages in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Cisco® Fast EtherChannel® Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. If the switch supports LACP then that should be used instead. On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=4ACTIVE laggport: bge0 flags=1MASTER ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
Re: LAGG bug or misconfiguration???
You're not looking for FEC or ethechannel or 802.3ad at all. What you're looking for, in the case of a *failover* configuration, is a spanning-tree portfast feature so that your port doesn't transition through the different spantree states before forwarding traffic. Kindly obtain the configuration from whoever has it and let us know. On 3/16/12 11:18 AM, Snoop wrote: Hi Dweimer and Damien, thanks for replying. The server is connected to a switch of the datacentre. The configuration of this switch is unknown to me and I obviously have no access to it but I truly believe that such an enterprise environment has management capabilities. Anyway, in which way the configuration would affect the lagg functionality? Might this issue be related to what stated in the FreeBSD LAGG pages in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Cisco® Fast EtherChannel® Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. If the switch supports LACP then that should be used instead. On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover
Re: LAGG bug or misconfiguration???
I've requested the configuration. I'll post that as soon as I have it. Thank you very much for your time. On Fri, 2012-03-16 at 12:10 +0100, Damien Fleuriot wrote: You're not looking for FEC or ethechannel or 802.3ad at all. What you're looking for, in the case of a *failover* configuration, is a spanning-tree portfast feature so that your port doesn't transition through the different spantree states before forwarding traffic. Kindly obtain the configuration from whoever has it and let us know. On 3/16/12 11:18 AM, Snoop wrote: Hi Dweimer and Damien, thanks for replying. The server is connected to a switch of the datacentre. The configuration of this switch is unknown to me and I obviously have no access to it but I truly believe that such an enterprise environment has management capabilities. Anyway, in which way the configuration would affect the lagg functionality? Might this issue be related to what stated in the FreeBSD LAGG pages in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Cisco® Fast EtherChannel® Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. If the switch supports LACP then that should be used instead. On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet
Re: LAGG bug or misconfiguration???
That's the STP configuration on my two switch ports: spanning-tree portfast spanning-tree bpduguard enable On Fri, 2012-03-16 at 12:10 +0100, Damien Fleuriot wrote: You're not looking for FEC or ethechannel or 802.3ad at all. What you're looking for, in the case of a *failover* configuration, is a spanning-tree portfast feature so that your port doesn't transition through the different spantree states before forwarding traffic. Kindly obtain the configuration from whoever has it and let us know. On 3/16/12 11:18 AM, Snoop wrote: Hi Dweimer and Damien, thanks for replying. The server is connected to a switch of the datacentre. The configuration of this switch is unknown to me and I obviously have no access to it but I truly believe that such an enterprise environment has management capabilities. Anyway, in which way the configuration would affect the lagg functionality? Might this issue be related to what stated in the FreeBSD LAGG pages in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Cisco® Fast EtherChannel® Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. If the switch supports LACP then that should be used instead. On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4
Re: LAGG bug or misconfiguration???
I confirm you should see fast transition for your VLANs to forwarding state. Are your ports in access or trunk mode ? If they're trunked, portfast alone won't do it, you need spanning-tree portfast trunk. Additionally, are you using link aggregation on the cisco swi ? (channel-group) On 3/16/12 5:31 PM, Snoop wrote: That's the STP configuration on my two switch ports: spanning-tree portfast spanning-tree bpduguard enable On Fri, 2012-03-16 at 12:10 +0100, Damien Fleuriot wrote: You're not looking for FEC or ethechannel or 802.3ad at all. What you're looking for, in the case of a *failover* configuration, is a spanning-tree portfast feature so that your port doesn't transition through the different spantree states before forwarding traffic. Kindly obtain the configuration from whoever has it and let us know. On 3/16/12 11:18 AM, Snoop wrote: Hi Dweimer and Damien, thanks for replying. The server is connected to a switch of the datacentre. The configuration of this switch is unknown to me and I obviously have no access to it but I truly believe that such an enterprise environment has management capabilities. Anyway, in which way the configuration would affect the lagg functionality? Might this issue be related to what stated in the FreeBSD LAGG pages in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Cisco® Fast EtherChannel® Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. If the switch supports LACP then that should be used instead. On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x
Re: LAGG bug or misconfiguration???
I actually don't know Damien. I'll have to have a chat with the network guy in the DC as I'm not managing the switch neither I have access to it, plus I'm not really a Cisco guy so I'll forward those questions to him. Moreover I'm getting a bit lost with this. If the ports are in trunk mode would this affect the FreeBSD lagg functionality? If yes how? Do I need spanning-tree portfast trunk to make it work properly? I really appreciate your useful inputs Damien. On Fri, 2012-03-16 at 17:49 +0100, Damien Fleuriot wrote: I confirm you should see fast transition for your VLANs to forwarding state. Are your ports in access or trunk mode ? If they're trunked, portfast alone won't do it, you need spanning-tree portfast trunk. Additionally, are you using link aggregation on the cisco swi ? (channel-group) On 3/16/12 5:31 PM, Snoop wrote: That's the STP configuration on my two switch ports: spanning-tree portfast spanning-tree bpduguard enable On Fri, 2012-03-16 at 12:10 +0100, Damien Fleuriot wrote: You're not looking for FEC or ethechannel or 802.3ad at all. What you're looking for, in the case of a *failover* configuration, is a spanning-tree portfast feature so that your port doesn't transition through the different spantree states before forwarding traffic. Kindly obtain the configuration from whoever has it and let us know. On 3/16/12 11:18 AM, Snoop wrote: Hi Dweimer and Damien, thanks for replying. The server is connected to a switch of the datacentre. The configuration of this switch is unknown to me and I obviously have no access to it but I truly believe that such an enterprise environment has management capabilities. Anyway, in which way the configuration would affect the lagg functionality? Might this issue be related to what stated in the FreeBSD LAGG pages in the handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Cisco® Fast EtherChannel® Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate aggregation with the peer or exchange frames to monitor the link. If the switch supports LACP then that should be used instead. On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: Sorry top posting from phone. Show your switch's port configurations. We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. On 15 Mar 2012, at 20:06, Snoop sn...@email.it wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x
LAGG bug or misconfiguration???
Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=4ACTIVE laggport: bge0 flags=1MASTER ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE __ Also nothing unusual on dmesg: ... bge0: link state changed to DOWN bge0: link state changed to UP bge1: link state changed to DOWN bge1: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP bge1: link state changed to DOWN bge1: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP bge1: link state changed to DOWN bge1: link state changed to UP ... The following
Re: LAGG bug or misconfiguration???
On 15.03.2012 14:06, Snoop wrote: Hi there, a while after setting up my new server (with 8 jails in it) I've decided (after postponing several times) to properly check the functionality of the lagg and the result was very disappointing. The test I've done is very simple. I've started copying a file from one site to another of my VPN network (from the server I've been testing the net to another node somewhere else) and in the meantime I've been physically disconnecting the main network cable to check the responsiveness of the lagg configuration. Then I've plugged the cable back to check if the traffic would switch back to the main NIC as it should. The result was basically this (lagg0 members: bge0 primary, bge1 secondary) - when bge0 unplugged the traffic switched almost instantaneously to bge1 - when bge0 plugged back in, the network stopped working completely with the two NICs polling synchronously until I manually unplug bge1. Then within 2-4 seconds traffic goes back on bge0 (I've been waiting for a little more than a minute maximum to avoid all the active connections on the server to timeout). Now, I've repeated the same test about 10-15 times randomly waiting for different times between the unplug-replug procedure. The result was always the same. So, below are the ipconfig outputs - before to start the test - when bge0 gets unplugged - when bge0 gets plugged back in I couldn't see anything odd. ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=4ACTIVE laggport: bge0 flags=1MASTER ___ lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:14:ee:00:8a:c0 inet xxx.xx.xx.224 netmask 0xff00 broadcast xxx.xx.xx.255 inet xxx.xx.xx.227 netmask 0x broadcast xxx.xx.xx.227 inet xxx.xx.xx.225 netmask 0x broadcast xxx.xx.xx.225 inet 172.16.3.2 netmask 0x broadcast 172.16.3.2 inet 172.16.3.3 netmask 0x broadcast 172.16.3.3 inet 172.16.3.4 netmask 0x broadcast 172.16.3.4 inet 172.16.3.5 netmask 0x broadcast 172.16.3.5 inet 172.16.3.6 netmask 0x broadcast 172.16.3.6 inet xxx.xx.xx.226 netmask 0x broadcast xxx.xx.xx.226 media: Ethernet autoselect status: active laggproto failover laggport: bge1 flags=0 laggport: bge0 flags=5MASTER,ACTIVE __ Also nothing unusual on dmesg: ... bge0: link state changed to DOWN bge0: link state changed to UP bge1: link state changed to DOWN bge1: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP bge1: link state changed to DOWN bge1: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP bge1: link state changed to
Re: Old Bug or not?
At 13:48 26/01/2012, you wrote: There seems to be an old BUG, http://osdir.com/ml/freebsd-bugs/2006-04/msg00309.html that has recently been noted on the Postfix forums. Was this bug ever actually addressed? In other words, is this an actual bug or is it working as intended? If it is a bug, and since it is apparently nearly 5 years old, will anyone actually ever look at it? The bug PR is at http://www.freebsd.org/cgi/query-pr.cgi?pr=95559cat=kern, it's marked as open. Have you checked your firewall? Perhaps the fix for pf works in yours. IMO it looks like Xing LI found how to solution this issue and forgot to say how. -- Jerry â ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Old Bug or not?
There seems to be an old BUG, http://osdir.com/ml/freebsd-bugs/2006-04/msg00309.html that has recently been noted on the Postfix forums. Was this bug ever actually addressed? In other words, is this an actual bug or is it working as intended? If it is a bug, and since it is apparently nearly 5 years old, will anyone actually ever look at it? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ The chicken that clucks the loudest is the one most likely to show up at the steam fitters' picnic. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Old Bug or not?
On Thu, Jan 26, 2012 at 07:48:18AM -0500, Jerry wrote: There seems to be an old BUG, http://osdir.com/ml/freebsd-bugs/2006-04/msg00309.html that has recently been noted on the Postfix forums. 403 Forbidden Was this bug ever actually addressed? In other words, is this an actual bug or is it working as intended? If it is a bug, and since it is apparently nearly 5 years old, will anyone actually ever look at it? Yuri pgpuXXC1pe4SC.pgp Description: PGP signature
Re: lang/lua fails to build on 9.0-STABLE amd64 - bug or config issue?
On 24 January 2012 02:12, Christer Solskogen
christer.solsko...@gmail.com wrote:
On Tue, Jan 24, 2012 at 12:22 AM, Lee Thomas lthomas_li...@lthomas.net
wrote:
Hello fellow FreeBSD users,
I ran across an odd issue compiling lua from ports on amd64 with FreeBSD
9.0-STABLE, and I'm not sure whether it's a bug or incorrect configuration
on my part. The lang/lua port throws a linker error, claiming to need -fPIC,
which is odd because the port Makefile seems to have logic to add that in,
but somehow the logic seems not to have any effect, at least in my case.
Making the port Makefile put ${CFLAGS} directly into lua's Makefile (patch
at the end of this mail) fixes matters for me, but I don't understand the
port infrastructure well enough to understand whether this patch represents
a bugfix or a workaround of some local configuration issue. Has anyone run
into this issue before? If this is a config issue, any hints on what might
be going on or how to dope it out?
I think I had the same problem about a moth ago. The problem was my
CFLAGS in make.conf.
You probably have CFLAGS=something, try setting it to CFLAGS?=something.
We note above that:
CFLAGS= -O2 -fno-strict-aliasing -pipe
since that tends to be the default anyway (see
/usr/share/mk/sys.mk ), you're generally better off
leaving it out entirely.
--
--
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
lang/lua fails to build on 9.0-STABLE amd64 - bug or config issue?
Hello fellow FreeBSD users,
I ran across an odd issue compiling lua from ports on amd64 with
FreeBSD 9.0-STABLE, and I'm not sure whether it's a bug or incorrect
configuration on my part. The lang/lua port throws a linker error,
claiming to need -fPIC, which is odd because the port Makefile seems to
have logic to add that in, but somehow the logic seems not to have any
effect, at least in my case. Making the port Makefile put ${CFLAGS}
directly into lua's Makefile (patch at the end of this mail) fixes
matters for me, but I don't understand the port infrastructure well
enough to understand whether this patch represents a bugfix or a
workaround of some local configuration issue. Has anyone run into this
issue before? If this is a config issue, any hints on what might be
going on or how to dope it out?
Thanks for your help,
Lee Thomas
The details:
#date
Mon Jan 23 18:01:30 EST 2012
#uname -a
FreeBSD Anon 9.0-STABLE FreeBSD 9.0-STABLE #0: Sat Jan 21 10:39:05 EST
2012 anon@Anon:/usr/obj/usr/src/sys/GENERIC amd64
#cat /etc/make.conf
CPUTYPE?=nocona
CFLAGS= -O2 -fno-strict-aliasing -pipe
COPTFLAGS= -O -pipe
#csup ports-supfile
Connected to 216.165.129.134
Updating collection ports-all/cvs
Finished successfully
#cd /usr/ports/lang/lua make clean build
=== Cleaning for lua-5.1.4_6
=== Vulnerability check disabled, database not found
=== License check disabled, port has not defined LICENSE
=== Extracting for lua-5.1.4_6
= SHA256 Checksum OK for lua-5.1.4.tar.gz.
= SHA256 Checksum OK for patch-lua-5.1.4-3.
=== Patching for lua-5.1.4_6
=== Applying distribution patches for lua-5.1.4_6
=== Applying FreeBSD patches for lua-5.1.4_6
=== lua-5.1.4_6 depends on executable: pkg-config - found
=== Configuring for lua-5.1.4_6
=== Building for lua-5.1.4_6
cd src make freebsd
make all MYCFLAGS=-DLUA_USE_LINUX MYLIBS=-Wl,-E -lreadline
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lapi.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lcode.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c ldebug.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c ldo.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c ldump.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lfunc.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c llex.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lgc.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lmem.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lobject.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lopcodes.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lparser.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lstate.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lstring.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c ltable.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c ltm.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lundump.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lvm.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lzio.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lauxlib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lbaselib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c ldblib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c liolib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c loslib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lmathlib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c ltablib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lstrlib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c loadlib.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c linit.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c lua.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c luac.c
cc -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -DLUA_USE_LINUX
-c print.c
cc -o liblua.so -O2 -fno-strict-aliasing -pipe -march=nocona -Wall
-DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o
ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o
lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o
lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o
lstrlib.o loadlib.o linit.o
ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o
Re: lang/lua fails to build on 9.0-STABLE amd64 - bug or config issue?
On Mon, Jan 23, 2012 at 04:22:30PM -0700, Lee Thomas wrote: Hello fellow FreeBSD users, I ran across an odd issue compiling lua from ports on amd64 with FreeBSD 9.0-STABLE, and I'm not sure whether it's a bug or incorrect configuration on my part. The lang/lua port throws a linker error, The same port builds fine on my machine (9.0-RELEASE, amd64, also CPUTYPE=nocona, otherwise standard settings in make.conf). #uname -a FreeBSD Anon 9.0-STABLE FreeBSD 9.0-STABLE #0: Sat Jan 21 10:39:05 EST 2012 anon@Anon:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD slackbox.erewhon.net 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 #cat /etc/make.conf CPUTYPE?=nocona CFLAGS= -O2 -fno-strict-aliasing -pipe COPTFLAGS= -O -pipe - # file: /etc/make.conf # host: slackbox.erewhon.net # Time-stamp: 2012-01-15 18:27:45 rsmith # $Id: a7a5c36f9b8474b6139154d7d7b8aa595415be86 $ # Type of CPU the system is built for. CPUTYPE=nocona # Compiler flags # Use standard settings. - #csup ports-supfile Connected to 216.165.129.134 Updating collection ports-all/cvs Finished successfully I tend to use portmaster, but I've got the same port version; lua-5.1.4_6. #cd /usr/ports/lang/lua make clean build === Cleaning for lua-5.1.4_6 === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Extracting for lua-5.1.4_6 = SHA256 Checksum OK for lua-5.1.4.tar.gz. = SHA256 Checksum OK for patch-lua-5.1.4-3. === Patching for lua-5.1.4_6 === Applying distribution patches for lua-5.1.4_6 === Applying FreeBSD patches for lua-5.1.4_6 === lua-5.1.4_6 depends on executable: pkg-config - found === Configuring for lua-5.1.4_6 === Building for lua-5.1.4_6 After builing, I get the following for lapi.*: # sha256 work/lua-5.1.4/src/lapi.* SHA256 (work/lua-5.1.4/src/lapi.c) = 6aa0d9fdd88b13fe46568ad6722ecf44164fb84476cfdf6480cf05b5704935f8 SHA256 (work/lua-5.1.4/src/lapi.h) = 4aea4c1b975d43184f4f1fd1a42c79cf11d74d2801315740cec07fe9abebb56d SHA256 (work/lua-5.1.4/src/lapi.o) = 08de497fe95c4afacd941f6aeede3d07db9fb08db7260efeffd5a4c0194bcb7e # cc --version cc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You could try building with clang, that works here as well; # make CC=clang and gives: # sha256 work/lua-5.1.4/src/lapi.o SHA256 (work/lua-5.1.4/src/lapi.o) = d96c0ae288387d9030e1228eaa03f9997b62e433b16ad7b9df959f99901bc301 Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpE2zganLIZb.pgp Description: PGP signature
Re: lang/lua fails to build on 9.0-STABLE amd64 - bug or config issue?
On Tue, Jan 24, 2012 at 12:22 AM, Lee Thomas lthomas_li...@lthomas.net wrote:
Hello fellow FreeBSD users,
I ran across an odd issue compiling lua from ports on amd64 with FreeBSD
9.0-STABLE, and I'm not sure whether it's a bug or incorrect configuration
on my part. The lang/lua port throws a linker error, claiming to need -fPIC,
which is odd because the port Makefile seems to have logic to add that in,
but somehow the logic seems not to have any effect, at least in my case.
Making the port Makefile put ${CFLAGS} directly into lua's Makefile (patch
at the end of this mail) fixes matters for me, but I don't understand the
port infrastructure well enough to understand whether this patch represents
a bugfix or a workaround of some local configuration issue. Has anyone run
into this issue before? If this is a config issue, any hints on what might
be going on or how to dope it out?
I think I had the same problem about a moth ago. The problem was my
CFLAGS in make.conf.
You probably have CFLAGS=something, try setting it to CFLAGS?=something.
--
chs,
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
BUG: scp -pr does not copy directories that have ':' sign in their names
HI, Tri. scp -pr * name@host:/home/dir does not copy files which have ':' sign in their names -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
BUG: snmpd or How to check where space is LOST
Здравствуйте, Robert. Вы писали 12 сентября 2011 г., 10:28:22: From kes-...@yandex.ru Mon Sep 12 00:51:16 2011 Date: Mon, 12 Sep 2011 08:51:27 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= kes-...@yandex.ru To: Robert Bonomi bon...@mail.r-bonomi.com Subject: Re[2]: How to check where space is LOST Caoaanoaoeoa, Robert. u ienaee 12 naioyaoy 2011 a., 4:33:25: From owner-freebsd-questi...@freebsd.org Sun Sep 11 17:23:57 2011 Date: Mon, 12 Sep 2011 01:23:32 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= kes-...@yandex.ru To: freebsd-questions@freebsd.org Subject: How to check where space is LOST Hi. I notice that some times /var is overfull # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ad1s1d989M349M561M38%/var # cd /var/ # du -h -d 1 98M. If I just #reboot system. I get that on /var is only 98M used. # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ad1s1d989M 98M891M12%/var How to obtain what take space on /var RB Probably, you *don't*. grin RB df _is_ telling the truth. RB 'du' is, arguably, 'telling lies'. RB The difference concerns files that have been deleted (rm) _after_ RB they have been opened, and not yet closed. The file handle/descriptor RB that has the file open silll has access to all the data in the file. RB but *NOTHING*ELSE* -- inlcuding 'du' -- can access that file, so the RB space occupied by that deletedd file is not counted. RB Note: this *IS* a FAQ. thank you very much. fstat -f /var tell me that process snmpd with file descriptor 3 take spece: RB It's not unreasonable that snmpd (the 'simple network management protocol' RB daemon) needs a *lot* of private storage. RB In short, don't worry about it. Ok, How you can explain this: # df -h /dev/ad1s1d989M138M772M15%/var # fstat -f /var USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root snmpd 205453 /var 47141 -rw--- 37217152 w root snmpd 205458 /var 47159 -rw-r- 728 r snmpd has 35MB of space # find /var -inum 47141 -ls output is empty (( # /usr/local/etc/rc.d/snmpd restart Stopping snmpd. Starting snmpd. # df -h /dev/ad1s1d989M102M808M11%/var # fstat -f /var/ USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root snmpd 407663 /var 47171 -rw--- 23311 w root snmpd 407668 /var 47159 -rw-r- 728 r after 3-4 weeks and snmpd overfull /var filesystem Test on other system: # df -h /dev/ad0s1d6.7G2.1G4.1G34%/var # fstat -f /var | grep snmp root snmpd 71403 -588866 -rw-r--r-- 947424261 w root snmpd 71408 /var 588842 -rw-r- 728 r # /usr/local/etc/rc.d/snmpd restart Stopping snmpd. Waiting for PIDS: 7140. Starting snmpd. # fstat -f /var | grep snmp root snmpd 233763 /var 588894 -rw-r--r-- 132 w root snmpd 233768 /var 588872 -rw-r- 728 r # df -h /dev/ad0s1d6.7G1.2G 5G19%/var It seems that that is the BUG of snmpd # snmpd -v NET-SNMP version: 5.5 Web: http://www.net-snmp.org/ Email: net-snmp-cod...@lists.sourceforge.net # uname -a FreeBSD flux 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Fri Jun 10 01:30:12 UTC 2011 adm@:/usr/obj/usr/src/sys/PAE_KES i386 -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
jail vnet bug
Hi all,
Not sure if this is a bug, but I'm using 8.1-RELEASE-p4 with VIMAGE enabled and
am experiencing something odd.
I set sysctl security.jail.mount_allowed=1 and then fire up a jail, all is good
(jail has value of 1).
I then set sysctl security.jail.enforce_statfs=1 and then restart the jail.
Again, all is good (jail has value of 1).
I then fire up my vimage jails, and all is bad. Values still show 0
(mount_allowed) and 2 (enforce_statfs).
So I went into the kernel and forced their default values, which appeared to
work, but only partly.
The following [undesirable] patch was enough to get enforce_statfs working:
--- sys/kern/kern_jail.c.orig 2011-08-26 23:41:27.0 -0700+++
sys/kern/kern_jail.c2011-08-27 00:44:45.0 -0700
@@ -202,7 +202,7 @@
#defineJAIL_DEFAULT_ALLOW PR_ALLOW_SET_HOSTNAME
-#defineJAIL_DEFAULT_ENFORCE_STATFS 2
+#defineJAIL_DEFAULT_ENFORCE_STATFS 1
static unsigned jail_default_allow = JAIL_DEFAULT_ALLOW;
static int jail_default_enforce_statfs = JAIL_DEFAULT_ENFORCE_STATFS;
#if defined(INET) || defined(INET6)
However, the following [equally undesirable] patch was NOT enough to get
mount(8) to work:
@@ -4113,4 +4114,4 @@
SYSCTL_PROC(_security_jail, OID_AUTO, mount_allowed,
CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_MPSAFE,
-NULL, PR_ALLOW_MOUNT, sysctl_jail_default_allow, I,
+(void *)1, PR_ALLOW_MOUNT, sysctl_jail_default_allow, I,
Processes in jail can mount/unmount jail-friendly file systems);
Here's what I'm getting for an error...
vnettest# ifconfig
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
inet 127.0.0.1 netmask 0xff00
epair0b: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether XX:XX:XX:XX:XX:XX
inet X.X.X.X netmask 0xff00 broadcast X.X.X.X
vnettest# sysctl security.jail.{jailed,mount_allowed,enforce_statfs}
security.jail.jailed: 1
security.jail.mount_allowed: 1
security.jail.enforce_statfs: 1
vnettest# mount build1:/repos /mnt
mount_nfs: /mnt, : Operation not permitted
Meanwhile, over in the jail (non-vnet):
vnettest# ifconfig -l
bge0 fxp0 plip0 ipfw0 lo0 epair0a bridge0
vnettest# sysctl security.jail.{jailed,mount_allowed,enforce_statfs}
security.jail.jailed: 1
security.jail.mount_allowed: 0
security.jail.enforce_statfs: 1
vnettest# mount build1:/repos /mnt
vnettest# df -Th
Filesystem Type SizeUsed Avail Capacity Mounted on
/dev/ad4s1fufs 137G4.1G122G 3%/
devfs devfs1.0K1.0K 0B 100%/dev
build1:/repos nfs 99G 63G 29G69%/mnt
vnettest# umount /mnt
vnettest# df -Th
Filesystem Type SizeUsed Avail Capacity Mounted on
/dev/ad4s1f ufs 137G4.1G122G 3%/
devfsdevfs1.0K1.0K 0B 100%/dev
Any advice would be helpful. The core issue is that we've finally achieved NFS
mounting within a jail (many thanks to Martin Matuska for his patch), but are
not able to replicate our success in a vnet jail.
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
_
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
8.2-release no sound. error driver bug: Unable to set devclass (devname: (null))
Behavior: tobago# kldload snd_driver driver bug: Unable to set devclass (devname: (null)) ppc0: parallel port not found. driver bug: Unable to set devclass (devname: (null)) ppc0: parallel port not found. ppc0: parallel port not found. driver bug: Unable to set devclass (devname: (null)) ppc0: parallel port not found. driver bug: Unable to set devclass (devname: (null)) ppc0: parallel port not found. driver bug: Unable to set devclass (devname: (null)) ppc0: parallel port not found. tobago# It turns out the kldload command itself have no output. all output are from dmesg. What can I / should I do? Interesting section of 'pciconf -lv': none1@pci0:0:4:0: class=0x040100 card=0x103b13bd chip=0x545510b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'AC'97 Audio Controller (M1563M Southbridge)' class = multimedia subclass = audio uname: FreeBSD tobago 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 By the way I tried to compile a kernel without ppc driver, thinking it causing trouble. Result is: tobago# kldload snd_driver driver bug: Unable to set devclass (devname: (null)) driver bug: Unable to set devclass (devname: (null)) driver bug: Unable to set devclass (devname: (null)) driver bug: Unable to set devclass (devname: (null)) driver bug: Unable to set devclass (devname: (null)) tobago# -- 我的博客： http://zhangweiwu.ixiezi.com/ 网站进化论 －－写给需要网站或后悔有了网站的人 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: fstat bug?
On Mon Mar 21 11, Laszlo Nagy wrote: Hi All, I have a Python program that goes up to 100% CPU. Just like this (top): you might want to re-post this message to freebsd-hackers@. in my experience freebsd-questions@ is suited for user-related questions and not that much for developers who seek answers to very techie questions. cheers. alex PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 80212 user1 2 440 70520K 16212K select 1 0:30 100.00% /usr/local/bin/python process_updates_ss_od.py -l 10 I have added extra logs and it turns out that there are two threads. One thread is calling time.sleep() and the other is calling os.stat call. (Actually it is calling os.path.isfile, but I hunted down the last link in the chain.) The most interesting thing is that the process is in SELECT state. As far as I know, CPU load should be 0% because select state should block program execution until the I/O completes. I must also tell you that the os.stat call is taking long because this system has about 7 million files on a slow disk under heavy load. It would be normal for an os.stat call to return after 10 seconds. I have no problem with that. But I think that the 100% CPU is not acceptable. I guess that the code is running a system call in kernel mode. I think this because I can send a KILL signal to it and the state changes to the following: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 80212 user1 2 440 70520K 15256K STOP5 1:27 100.00% /usr/local/bin/python process_updates_ss_od.py -l 10 So the state of the process changes to STOP, but the program does not stop until the os.stat call returns back. Sometimes for a minute. Could it be a problem with the operation system? Is it possible that an os.stat call requires 100% CPU power from the OS? (I believe that os.stat ends in fstat()). Or is it a problem with the Python implementation? (Unfortunately I cannot give you an example program. Giving an example would require giving you a slow I/O device with millions of files on it.) OS version: FreeBSD 8.1-STABLE amd64 Python version: 2.6.6 Thanks, Laszlo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- a13x ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
fstat bug?
Hi All, I have a Python program that goes up to 100% CPU. Just like this (top): PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 80212 user1 2 440 70520K 16212K select 1 0:30 100.00% /usr/local/bin/python process_updates_ss_od.py -l 10 I have added extra logs and it turns out that there are two threads. One thread is calling time.sleep() and the other is calling os.stat call. (Actually it is calling os.path.isfile, but I hunted down the last link in the chain.) The most interesting thing is that the process is in SELECT state. As far as I know, CPU load should be 0% because select state should block program execution until the I/O completes. I must also tell you that the os.stat call is taking long because this system has about 7 million files on a slow disk under heavy load. It would be normal for an os.stat call to return after 10 seconds. I have no problem with that. But I think that the 100% CPU is not acceptable. I guess that the code is running a system call in kernel mode. I think this because I can send a KILL signal to it and the state changes to the following: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 80212 user1 2 440 70520K 15256K STOP5 1:27 100.00% /usr/local/bin/python process_updates_ss_od.py -l 10 So the state of the process changes to STOP, but the program does not stop until the os.stat call returns back. Sometimes for a minute. Could it be a problem with the operation system? Is it possible that an os.stat call requires 100% CPU power from the OS? (I believe that os.stat ends in fstat()). Or is it a problem with the Python implementation? (Unfortunately I cannot give you an example program. Giving an example would require giving you a slow I/O device with millions of files on it.) OS version: FreeBSD 8.1-STABLE amd64 Python version: 2.6.6 Thanks, Laszlo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Bug report marked [regression]
If my bug report is marked [regression] what does that mean? Am I a troglodyte or a Luddite or something? -- Lars Eighner http://www.larseighner.com/index.html 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bug report marked [regression]
On Sun, 6 Mar 2011, Lars Eighner wrote: If my bug report is marked [regression] what does that mean? Am I a troglodyte or a Luddite or something? Regression is something that used to work but doesn't any more. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bug report marked [regression]
On Sun 06 Mar 2011 at 10:58:57 PST Warren Block wrote: On Sun, 6 Mar 2011, Lars Eighner wrote: If my bug report is marked [regression] what does that mean? Am I a troglodyte or a Luddite or something? Regression is something that used to work but doesn't any more. Like me. I'm retired now, so the description fits. ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Bug in routed?
I'm posting this in questions because 1) I'm not sure if it's really a defect, and 2) I'm not sure what other list might be more appropriate. I've been experimenting with modifications to the i386 platform in STABLE-8 to support 64-bit time_t values. After changing sys/i386/include/_types.h so that __time_t is defined as __int64_t, I received a warning when compiling sbin/routed/if.c that complained about passing a time_t for %ld. The following patch illustrates the change I made to fix this: --- orig/if.c 2011-03-05 14:25:47.0 -0800 +++ new/if.c2011-03-05 14:26:01.0 -0800 @@ -950,8 +950,8 @@ trace_act(interface %s has been off %ld seconds; forget it, ifp-int_name, - (long)now.tv_sec- - ifp-int_data.ts); + (long)(now.tv_sec- + ifp-int_data.ts)); ifdel(ifp); } continue; I'm guessing the original intent here was for the result of the subtraction to be passed as a long to trace_act(), but in actuality it's passed as a time_t. The original code compiles just fine if time_t and long are the same size. Additional note, this particular code fragment does not seem to exist in -current, so the issue appears limited to -stable. - Milo Hyson Chief Scientist CyberLife Labs, Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
BUG: freebsd.org/ru/releases
HI, Freebsd-questions. http://www.freebsd.org/ru/releases/ on this page is wrong information about releases. Old release is 6.0 and last is 8.1 on march 2006!! year. -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: BUG: freebsd.org/ru/releases
Hi, Reference: From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= kes-...@yandex.ru Reply-to: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= kes-...@yandex.ru Date: Sat, 27 Nov 2010 18:38:03 +0200 Message-id: 1071667463.20101127183...@yandex.ru =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= wrote: HI, Freebsd-questions. http://www.freebsd.org/ru/releases/ on this page is wrong information about releases. Old release is 6.0 and last is 8.1 on march 2006!! year. Please file a change request: man send-pr send-pr Which both: - lodgess in bug database till someone fixes it - sends a mail to people who have commit privilege to fix it. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com If I've not replied, please resend, Some personal mail to me received before 12:40 Sun 20 Nov 2010 +01:00, may have been zapped by spam filter; Fixed 17:30 Thu 25 Nov 2010 CET. Mail plain text; Not quoted-printable, or HTML or base 64. Avoid top posting, it cripples itemised cumulative responses. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
BUG: wrong log messages
Hi, Freebsd-questions. Nov 18 20:27:54 meta-up kernel: Nov 18 20:29:11 meta-up kernel: 110ip11f0w: ipfw: 102 102D enyD enTyCP T1C9P 192.168.2.173:4425 192.168.168.155:445 out via re0 Nov 18 20:32:30 meta-up kernel: 110 iefw: 102 Deny UDP 192.168.2.90:54625 192.168.1.33:59306 out via re0 Nov 18 20:33:55 meta-up kernel: 1u0 ipa re0 Nov 18 20:42:07 meta-up kernel: Nov 18 20:47:34 meta-up kernel: 111010iippffww:: 110022 DDeennyy UUDDPP 118982..9136.86.23..41931::1500030698 11929.21.61868.. 21..91073::1417464787 oouutt vviiaa rree00 sources 17.11.2010 # uname -a FreeBSD meta-up 9.0-CURRENT FreeBSD 9.0-CURRENT #6: Wed Nov 17 17:35:17 EET 2010 a...@meta-up:/usr/obj/usr/src/sys/KES_KERN_v9 i386 -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: BUG: wrong log messages
2010/11/19 Коньков Евгений kes-...@yandex.ru Hi, Freebsd-questions. Nov 18 20:27:54 meta-up kernel: Nov 18 20:29:11 meta-up kernel: 110ip11f0w: ipfw: 102 102D enyD enTyCP T1C9P 192.168.2.173:4425 192.168.168.155:445 out via re0 Nov 18 20:32:30 meta-up kernel: 110 iefw: 102 Deny UDP 192.168.2.90:54625 192.168.1.33:59306 out via re0 Nov 18 20:33:55 meta-up kernel: 1u0 ipa re0 Nov 18 20:42:07 meta-up kernel: Nov 18 20:47:34 meta-up kernel: 111010iippffww:: 110022 DDeennyy UUDDPP 118982..9136.86.23..41931::1500030698 11929.21.61868.. 21..91073::1417464787 oouutt vviiaa rree00 This particular bug of overlapping output from multiple-core machines has been around for years. I don't think it's going to get fixed anytime soon. -- Jonathan Chen j...@chen.org.nz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
BUG: sysctl net.isr.swi_count negative value
Hi, Freebsd-questions. net.isr.swi_count: -1692211928 as I think count can not be negative. in this case it is. Is this a bug or negative value means some special? -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: BUG: sysctl net.isr.swi_count negative value
On Sat Nov 13 10, ??? ??? wrote: Hi, Freebsd-questions. net.isr.swi_count: -1692211928 as I think count can not be negative. in this case it is. Is this a bug or negative value means some special? what is the output of 'uname -a'? looks like a 32 bit integer is being used for net.isr.swi_count which you managed to overrun. i'm running HEAD and that sysctl parameter doesn't exist: otaku% sysctl net.isr.swi_count sysctl: unknown oid 'net.isr.swi_count' seems pluknet posted the same one year ago [1] cheers. alex [1] http://markmail.org/message/qc34d5z6uyyet7nx -- ? ?, ??? mailto:kes-...@yandex.ru -- a13x ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
2010/7/21 Dan Nelson dnel...@allantgroup.com:
In the last episode (Jul 21), Jens Rehsack said:
On 07/16/10 18:13, Dan Nelson wrote:
Hi Dan,
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name,
$grpass, $gid, $members ) = getgrent() ) { print $name is returned
more than once (No $dupchk{$name} comes here)\n if( $dupchk{$name}++
); print Dumper( [ $name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups
and
my LDAP source, but that's expected.
You can see here
http://www.cpantesters.org/cpan/report/f5100ac6-9418-11df-9ebc-c4a68065c34d
the typical error picture. FreeBSD is the only system, where this error
occurs.
I don't know how to read perl's test output; what part of that report
failed, and how do you know it was due to getgrent returning duplicate
values?
Because I know the error picture - I've seen it on my FreeBSD box first.
I probably should add some diag() output for failing tests ...
BTW - I ran your one-liner above on a SLES 10.2 Linux box and a Solaris 10u7
box, and got duplicate entries where groups existed in both /etc/groups and
LDAP, just like on FreeBSD. I think you may be relying on behaviour that
getgrent doesn't guarantee on any OS.
But the duplicated entries I get are not duplicated in the source. I sent you my
/var/yp/groups file and the output of my one-liner.
I have no LDAP setup to try out, but in this case my workaround could be a good
idea.
Best regards,
Jens
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 18:13, Dan Nelson wrote:
Hi Dan,
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
You can see here
http://www.cpantesters.org/cpan/report/f5100ac6-9418-11df-9ebc-c4a68065c34d
the typical error picture. FreeBSD is the only system, where this error
occurs.
I rate it as a bug - but I will write merge code for the duplicated entries.
Best regards,
Jens
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 21), Jens Rehsack said:
On 07/16/10 18:13, Dan Nelson wrote:
Hi Dan,
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name,
$grpass, $gid, $members ) = getgrent() ) { print $name is returned
more than once (No $dupchk{$name} comes here)\n if( $dupchk{$name}++
); print Dumper( [ $name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups
and
my LDAP source, but that's expected.
You can see here
http://www.cpantesters.org/cpan/report/f5100ac6-9418-11df-9ebc-c4a68065c34d
the typical error picture. FreeBSD is the only system, where this error
occurs.
I don't know how to read perl's test output; what part of that report
failed, and how do you know it was due to getgrent returning duplicate
values?
BTW - I ran your one-liner above on a SLES 10.2 Linux box and a Solaris 10u7
box, and got duplicate entries where groups existed in both /etc/groups and
LDAP, just like on FreeBSD. I think you may be relying on behaviour that
getgrent doesn't guarantee on any OS.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
2010/7/16 Dan Nelson dnel...@allantgroup.com: In the last episode (Jul 16), Ashish SHUKLA said: Dan Nelson writes: In the last episode (Jul 15), Jens Rehsack said: Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The above output looks perfect, and should match the top three lines in /your etc/passwd files. Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. Was difficult for me to format the single liner ;) To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Could you please take a look to my other mail (getgrent related) - there seems another bug ... Try the following patch: Can I do this without a full world rebuild? (I do not develop in FBSD actively). Otherwise I recommend (the test case was in OP) that someone with a separate test box tries it out and commit it etc. I had to develop a workaround for all other boxes anyway. Thank you very much, Jens Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: 2010/7/16 Dan Nelson dnel...@allantgroup.com: [...] Try the following patch: Thanks, I'll try it when I'm on my FreeBSD box. Can I do this without a full world rebuild? (I do not develop in FBSD actively). Otherwise I recommend (the test case was in OP) that someone with a separate test box tries it out and commit it etc. I don't think you need full world rebuild, just rebuilding world should do it. I had to develop a workaround for all other boxes anyway. As a workaround you can use setpwent(3). -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things.” (Robert A. Heinlein, 1973) pgpEMMcLPMPwi.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 08:36, Ashish SHUKLA wrote: Jens Rehsack writes: 2010/7/16 Dan Nelsondnel...@allantgroup.com: [...] Try the following patch: Thanks, I'll try it when I'm on my FreeBSD box. Great \o/ [...] I had to develop a workaround for all other boxes anyway. As a workaround you can use setpwent(3). I cached the entires - I rate setpwent as to dangerous. You can take a look at http://cpansearch.perl.org/src/REHSACK/DBD-Sys-0.01_01/lib/DBD/Sys/Plugin/Unix/Users.pm Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? You can take a look at http://cpansearch.perl.org/src/REHSACK/DBD-Sys-0.01_01/lib/DBD/Sys/Plugin/Unix/Users.pm Jens -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Q: Why UNIX geeks feel the need of a wife ? A: Since all UNIX geeks possess a large fortune db and according to Law of Jane Austen, It is a universal truth that a single man with a large fortune is in need of a wife.” (abbe, 2009) pgpuRlGdT7Don.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. , an excerpt from getpwent(3) | The setpassent() function accomplishes two purposes. First, it causes | getpwent() to ``rewind'' to the beginning of the database. Additionally, | if stayopen is non-zero, file descriptors are left open, significantly | speeding up subsequent accesses for all of the routines. (This latter | functionality is unnecessary for getpwent() as it does not close its file | descriptors by default.) | | It is dangerous for long-running programs to keep the file descriptors | open as the database will become out of date if it is updated while the | program is running. | | The setpwent() function is identical to setpassent() with an argument of | zero. ` I can't see anything which says about modifying NSS database. AFAIK none of the NSS routines allow you to write on database, you've to use the database specific method to modify the database. HTH -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Age is not an accomplishment, and youth is not a sin.” (Robert A. Heinlein, Methuselah's Children, 1958) pgpwVZo684yN8.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 09:59, Ashish SHUKLA wrote: Jens Rehsack writes: On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. , an excerpt from getpwent(3) [...] ` I can't see anything which says about modifying NSS database. AFAIK none of the NSS routines allow you to write on database, you've to use the database specific method to modify the database. You're absolutely right - I never took a deeper look, because I always was only interested to read the (user|group) data and expected setpwent to modify such an entry. A quick look into Stevens Advanced Programming in the UNIX environment could had enlighten myself. Sorry that I didn't RTFM carefully. Best regards and many, many thanks, Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: [...] You're absolutely right - I never took a deeper look, because I always was only interested to read the (user|group) data and expected setpwent to modify such an entry. Its UNIX :P A quick look into Stevens Advanced Programming in the UNIX environment could had enlighten myself. Sorry that I didn't RTFM carefully. No problems. -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Software and cathedrals are much the same - first we build them, then we pray.” (anonymous) pgp1S6yBF1i4t.pgp Description: PGP signature
Re: getpwent bug?
In the last episode (Jul 16), Jens Rehsack said: 2010/7/16 Dan Nelson dnel...@allantgroup.com: In the last episode (Jul 16), Ashish SHUKLA said: Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. Was difficult for me to format the single liner ;) To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Could you please take a look to my other mail (getgrent related) - there seems another bug ... Do you have another one-liner that will reproduce it? A simple /usr/bin/getent group doesn't return dupes for me. Oddly enough, the *grent code doesn't use an internal counter, so the bug you found in endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that easy to read). Try the following patch: Can I do this without a full world rebuild? (I do not develop in FBSD actively). Assuming your test programs are dynamically linked, you only need to rebuld libc. Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
2010/7/16 Dan Nelsondnel...@allantgroup.com:
In the last episode (Jul 16), Ashish SHUKLA said:
Well, OP is also invoking 'endpwent()' after every 'getpwent()'
invocation which according to GNU/Linux's glibc and NetBSD's libc (as
OP mentioned) should rewind the position in passwd database to the
beginning.
Ah. I missed the endpwent calls.
Was difficult for me to format the single liner ;)
To me it definitely looks like a bug in FreeBSD's getpw*() family of
functions.
As tested using sysutils/lsof, in the following program in FreeBSD, the
descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but
position in database is never rewinded as shown in the output.
It looks like the *pwent functions keep an internal counter that
endpwent doesn't reset.
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that easy
to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
Best regards,
Jens
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 18:13, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
The dups I got are not duplicate:
$ less /var/yp/group
# $FreeBSD: src/etc/group,v 1.19.2.3 2002/06/30 17:57:17 des Exp $
#
wheel:*:0:root,trevor
staff:*:20:root
win32::1001:melanie,sarah
os2::1002:
dos::1003:
unix::1004:
music::1005:melanie,sarah
gamers::1006:
devel::1007:trevor
wwwdevel::15000:wwwglobal,trevor
All the rest (see attachment) are from /etc/group.
Jens
$VAR1 = [
'wheel',
'*',
0,
'root trevor mel'
];
$VAR1 = [
'daemon',
'*',
1,
''
];
$VAR1 = [
'kmem',
'*',
2,
''
];
$VAR1 = [
'sys',
'*',
3,
''
];
$VAR1 = [
'tty',
'*',
4,
''
];
$VAR1 = [
'operator',
'*',
5,
'root'
];
$VAR1 = [
'mail',
'*',
6,
''
];
$VAR1 = [
'bin',
'*',
7,
''
];
$VAR1 = [
'news',
'*',
8,
''
];
$VAR1 = [
'man',
'*',
9,
''
];
$VAR1 = [
'games',
'*',
13,
''
];
$VAR1 = [
'ftp',
'*',
14,
''
];
$VAR1 = [
'staff',
'*',
20,
''
];
$VAR1 = [
'sshd',
'*',
22,
''
];
$VAR1 = [
'smmsp',
'*',
25,
''
];
$VAR1 = [
'mailnull',
'*',
26,
''
];
$VAR1 = [
'guest',
'*',
31,
''
];
$VAR1 = [
'bind',
'*',
53,
''
];
$VAR1 = [
'proxy',
'*',
62,
''
];
$VAR1 = [
'authpf',
'*',
63,
''
];
$VAR1 = [
'_pflogd',
'*',
64,
''
];
$VAR1 = [
'_dhcp',
'*',
65,
''
];
$VAR1 = [
'uucp',
'*',
66,
''
];
$VAR1 = [
'dialer',
'*',
68,
''
];
$VAR1 = [
'network',
'*',
69,
''
];
$VAR1 = [
'audit',
'*',
77,
''
];
$VAR1 = [
'www',
'*',
80,
''
];
$VAR1 = [
'oper',
'*',
200,
'root trevor pgsql'
];
$VAR1 = [
'nogroup',
'*',
65533,
''
];
$VAR1 = [
'nobody',
'*',
65534,
''
];
$VAR1 = [
'messagebus',
'*',
556,
''
];
$VAR1 = [
'polkit',
'*',
559,
''
];
$VAR1 = [
'haldaemon',
'*',
560,
''
];
$VAR1 = [
'avahi',
'*',
558,
''
];
$VAR1 = [
'gdm',
'*',
92,
''
];
$VAR1 = [
'pgsql',
'*',
70,
''
];
smmsp is returned more than once (No 2 comes here)
$VAR1 = [
'smmsp',
'*',
25,
''
];
guest is returned more than once (No 2 comes here)
$VAR1 = [
'guest',
'*',
31,
''
];
authpf is returned more than once (No 2 comes here)
$VAR1 = [
'authpf',
'*',
63,
''
];
$VAR1 = [
'devel',
'',
1007,
'trevor'
];
tty is returned more than once (No 2 comes here)
$VAR1 = [
'tty',
'*',
4,
''
];
bin is returned
getpwent bug?
Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The correct output should be (taken from a NetBSD system): perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; Taking a look to http://www.cpantesters.org/distro/D/DBD-Sys.html#DBD-Sys-0.01, this issue is not limited to FreeBSD 7.3 - it occures on FreeBSD 7.2 and 8.0, too. I tried several perl versions on my box (perl5.8 from ports, perl5.10.1 from pkgsrc and the release candidate of perl5.12.0) - with the same result. Maybe someone could take a look? If I can provide additional information, please let me know. Best regards, Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 15), Jens Rehsack said: Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The above output looks perfect, and should match the top three lines in your /etc/passwd files. The correct output should be (taken from a NetBSD system): perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; This output looks wrong, unless NetBSD has three identical root lines at the top of its passwd file. Taking a look to http://www.cpantesters.org/distro/D/DBD-Sys.html#DBD-Sys-0.01, this issue is not limited to FreeBSD 7.3 - it occures on FreeBSD 7.2 and 8.0, too. I see a bunch of failed FreeBSD test lines, but I don't see anything relating to getpwent or getreant in the test failure output. Just lines like Parse errors: Bad plan. You planned 16 tests but ran 12 -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Dan Nelson writes:
In the last episode (Jul 15), Jens Rehsack said:
Hi all,
I detected an issue with getpwent on my FreeBSD test box:
perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e);
endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e =
getpwent(); print Dumper(\...@e); endpwent();'
$VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ];
$VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0
];
$VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes',
'/root', '/usr/sbin/nologin', 0 ];
I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD
7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010
r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64
The above output looks perfect, and should match the top three lines in your
/etc/passwd files.
Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation
which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned)
should rewind the position in passwd database to the beginning.
To me it definitely looks like a bug in FreeBSD's getpw*() family of
functions.
As tested using sysutils/lsof, in the following program in FreeBSD, the
descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but
position in database is never rewinded as shown in the output.
#v+
#include pwd.h
#include stdio.h
int
main()
{
struct passwd* pw;
int i;
char ch;
for(i = 0; i 3; i++)
{
printf(Doing getpwent(). Press any key to continue...);
while(getchar() != '\n');
pw = getpwent();
printf(%s:%d:%d\n, pw-pw_name, pw-pw_uid, pw-pw_gid);
endpwent();
}
}
#v-
Output on FreeBSD 8.1-RC2:
#v+
%./pwent
Doing getpwent(). Press any key to continue...
root:0:0
Doing getpwent(). Press any key to continue...
toor:0:0
Doing getpwent(). Press any key to continue...
daemon:1:1
#v-
Output on GNU/Linux:
#v+
% ./pwent
Doing getpwent(). Press any key to continue...
root:0:0
Doing getpwent(). Press any key to continue...
root:0:0
Doing getpwent(). Press any key to continue...
root:0:0
#v-
HTH
--
Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0
freebsd.org!ashish | http://people.freebsd.org/~ashish/
“How can I possibly put a new idea into your heads, if I do not first
remove your delusions?” (Robert A. Heinlein, Life-Line, 1939)
pgpSNaH90CVKQ.pgp
Description: PGP signature
Re: getpwent bug?
In the last episode (Jul 16), Ashish SHUKLA said: Dan Nelson writes: In the last episode (Jul 15), Jens Rehsack said: Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The above output looks perfect, and should match the top three lines in /your etc/passwd files. Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Try the following patch: Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
mixer relative values don't work without a dev: bug or by design?
% mixer vol +4
Setting the mixer vol from 90:90 to 94:94.
% mixer vol -4
Setting the mixer vol from 94:94 to 90:90.
% mixer 95
Setting the mixer vol from 90:90 to 95:95.
% mixer 90
Setting the mixer vol from 95:95 to 90:90.
% mixer +5
Setting the mixer vol from 90:90 to 5:5.
% mixer -5
usage: mixer [-f device] [-s | -S] [dev [+|-][voll[:[+|-]volr]] ...
mixer [-f device] [-s | -S] recsrc ...
mixer [-f device] [-s | -S] {^|+|-|=}rec rdev ...
devices: vol, bass, treble, pcm, mic, rec
rec devices: mic
I have a patch that changes this so that the latter two commands work
like the first few and I'm wondering if this would be wanted?
--
Eitan Adler
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
port system bug report
Egorka# uname -a FreeBSD Egorka.noc.kstu-kai.ru 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Thu Apr 15 16:40:38 MSD 2010 Egorka# cd /usr/ports/ports-mgmt/portupgrade Egorka# make clean Makefile, line 60: Could not find /usr/ports/misc/ldconfig_compat/bsd.ldconfig.mk make: fatal errors encountered -- cannot continue Egorka# cd /usr/ports/ Egorka# make search name=ldconfig_compat Port: ldconfig_compat-1.0_8 Path: /usr/ports/misc/ldconfig_compat Info: Ldconfig compatibility script Maint: f...@freebsd.org B-deps: R-deps: WWW: Port: misc/ldconfig_compat Moved: Date: 2010-05-14 Reason: Supported releases don't need the port anymore Problem can be solved by commenting of line 60 in /usr/ports/ports-mgmt/portupgrade/Makefile ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Suspect results from iostat--FBSD bug?
We use iostat to collect statistics of hard drive activity. We've been seeing some values for the transaction wait column that look suspicious. This is easy to reproduce by just running iostat repeatedly over a short period of time, as I show below. Notice the third from last column. From what I understand, when run in this fashion the values displayed are averaged over the system uptime. I'd expect then for the transaction wait value to not take these sudden dips. Is there an explanation for this? # for ((i=1; i =100; i++)); do iostat -dxI ad8|tail +3; sleep 5; done ad8 10291.0 569044.0 151986.0 10164944.0 4294967295 47.7 93 ad8 10304.0 570070.0 152012.0 10185395.0 4294967295 47.6 93 ad8 10312.0 571047.0 152028.0 10204575.0 85 47.5 93 ad8 10317.0 571729.0 152038.0 10217633.0 4294967295 47.5 93 ad8 10321.0 572363.0 152046.0 10230152.0 4294967295 47.4 93 ad8 10324.0 573863.0 152052.0 10247668.0 4294967295 48.2 93 ad8 10325.0 574438.0 152054.0 10259296.0 4294967295 48.1 93 ad8 10330.0 575150.0 152078.0 10273362.0 4294967295 48.1 93 ad8 10332.0 575693.0 152082.0 10283567.0 4294967295 48.0 93 ad8 10334.0 576478.0 152086.0 10298971.0 4294967295 48.0 93 ad8 10337.0 577363.0 152092.0 10316766.0 4294967295 47.9 93 ad8 10340.0 578501.0 152098.0 10328958.0 4294967295 48.4 93 ad8 10343.0 579682.0 152104.0 10352494.0 4294967295 48.3 93 ad8 10349.0 580806.0 152116.0 10375251.0 4294967295 48.2 93 ad8 10356.0 581462.0 152200.0 10387402.00 48.1 93 ad8 10362.0 582392.0 152212.0 10405738.0 4294967295 48.1 93 ad8 10367.0 583326.0 15.0 10424055.0 4294967295 48.0 93 ad8 10367.0 584412.0 15.0 10432981.0 4294967295 48.7 93 ad8 10376.0 585764.0 152240.0 10460020.0 4294967295 48.6 93 ad8 10377.0 586649.0 152242.0 10477525.0 4294967295 48.5 93 ad8 10382.0 587266.0 152252.0 10488950.0 4294967295 48.5 93 ad8 10392.0 587977.0 152272.0 10503115.0 4294967295 48.4 93 ad8 10402.0 588713.0 152292.0 10518177.0 4294967295 48.4 93 ad8 10403.0 589831.0 152294.0 10527746.0 16 48.8 93 ad8 10419.0 590811.0 152326.0 10547455.0 4294967295 48.7 93 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Suspect results from iostat--FBSD bug?
On Wed, 5 May 2010 07:34:55 -0500, Peter Steele pste...@maxiscale.com wrote:
We use iostat to collect statistics of hard drive activity. We've been
seeing some values for the transaction wait column that look
suspicious. This is easy to reproduce by just running iostat
repeatedly over a short period of time, as I show below. Notice the
third from last column. From what I understand, when run in this
fashion the values displayed are averaged over the system uptime. I'd
expect then for the transaction wait value to not take these sudden
dips. Is there an explanation for this?
# for ((i=1; i =100; i++)); do iostat -dxI ad8|tail +3; sleep 5; done
ad8 10291.0 569044.0 151986.0 10164944.0 4294967295 47.7 93
ad8 10304.0 570070.0 152012.0 10185395.0 4294967295 47.6 93
ad8 10312.0 571047.0 152028.0 10204575.0 85 47.5 93
This looks like a bug in iostat. 4294967295 == 2 * 32 - -1
It seems that some call returns (unsigned long)-1, e.g. to indicate a
failing system/library call but iostat still prints the result:
: keram...@kobe:/home/keramida$ cat -n demo.c
: 1 #include limits.h
: 2 #include stdio.h
: 3
: 4 int
: 5 main(void)
: 6 {
: 7 (void)printf(-1 = %lu\n, (unsigned long)-1);
: 8 return 0;
: 9 }
: keram...@kobe:/home/keramida$ cc demo.c
: keram...@kobe:/home/keramida$ ./a.out
: -1 = 4294967295
: keram...@kobe:/home/keramida$
Which _precise_ version of FreeBSD are you using?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Suspect results from iostat--FBSD bug?
This looks like a bug in iostat. 4294967295 == 2 * 32 - -1 It seems that some call returns (unsigned long)-1, e.g. to indicate a failing system/library call but iostat still prints the result: Which _precise_ version of FreeBSD are you using? Well, that's a good question. The particular version I am running right now is basically FreeBSD 9.0-CURRENT (well, from a free weeks ago anyway) with lots of local kernel mods (to support drive pull primarily). I guess we could very well be hitting a bug in this 9.0 code since it hasn't officially been stamped as released... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[Full-disclosure] FreeBSD and OpenBSD ftpd bug (not exploitable?)
Dear all,
Found this in full-disclosure mailing list.
-- Forwarded message --
From: Kingcope kco...@googlemail.com
Date: Fri, Mar 5, 2010 at 11:19 PM
Subject: [Full-disclosure] FreeBSD and OpenBSD ftpd bug (not exploitable?)
To: full-disclos...@lists.grok.org.uk, bugt...@securityfocus.com
FreeBSD ftpd globbing bug - null pointer dereference ?
Affected FreeBSD Releases
+-+-+-+-+-+-+-+-+-+
FreeBSD 8.0, 6.3 and 4.9
Affected OpenBSD Releases
+-+-+-+-+-+-+-+-+-+
OpenBSD 4.6
Testing Environment
+-+-+-+-+-+-+-+-+-+
FreeBSD localhost.Belkin 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21
15:48:17 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
i386
Full Description
+-+-+-+-+-+-+-+-+-+
FreeBSD (tested back to 4.9-Release) (and OpenBSD 4.6) has a bug in its ftpd
when handling globbing requests.
My investigation results in this being a null pointer dereference in
popen.c.
I am not sure if this could be a heap overrun, but I don't think so.
from popen.c:
/* glob each piece */
gargv[0] = argv[0];
for (gargc = argc = 1; argv[argc] gargc (MAXGLOBARGS-1); argc++) {
glob_t gl;
int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_TILDE;
memset(gl, 0, sizeof(gl));
gl.gl_matchc = MAXGLOBARGS;
flags |= GLOB_LIMIT;
[1] if (glob(argv[argc], flags, NULL, gl))
gargv[gargc++] = strdup(argv[argc]);
[2] else
[3] for (pop = gl.gl_pathv; *pop gargc (MAXGLOBARGS-1);
pop++)
gargv[gargc++] = strdup(*pop);
globfree(gl);
}
At [1] glob() is called. if theres a long directory (for example A x 200)
and a request like described
in how to repeat this problem is sent to the ftpd it crashes. My
assumption is because it lands in the
else clause [2], glob doesn't fail but gives back a zeroed out gl structure.
In [3] then there's no check
if pop is null and therefore *pop gets dereferenced which is a null pointer
and the ftpd instance crashes.
Could someone please shed some light into why glob doesn't fail but gives a
zeroed out structure back?
How to repeat the problem
+-+-+-+-+-+-+-+-+-+-+-+-+-+
$ ftp 192.168.2.11
Connected to 192.168.2.11.
220 localhost.Belkin FTP server (Version 6.00LS) ready.
Name (192.168.2.11:nr): kcope
331 Password required for kcope.
Password:
230 User kcope logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp mkdir
W
257
W
directory created.
ftp ls {W*/../W*/../W*/../W*/../W*/../W*/../W*/}
200 PORT command successful.
---snip---
on the other side:
---snip---
0x282261e5 in read () at read.S:3
3 RSYSCALL(read)
Current language: auto; currently asm
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0805622c in getline ()
(gdb) i r
eax0x0 0
ecx0x0 0
edx0x0 0
ebx0xbfbfd911 -1077946095
esp0xbfbfba70 0xbfbfba70
ebp0xbfbfcc08 0xbfbfcc08
esi0x1 1
edi0xbfbfcbf4 -1077949452
eip0x805622c 0x805622c
eflags 0x10293 66195
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
(gdb) x/10i $eip
0x805622c getline+12620: mov(%edx),%eax
0x805622e getline+12622: setle %cl
0x8056231 getline+12625: mov%ecx,%esi
0x8056233 getline+12627: test %eax,%eax
0x8056235 getline+12629: je 0x8056281 getline+12705
0x8056237 getline+12631: test %cl,%cl
0x8056239 getline+12633: je 0x8056281 getline+12705
0x805623b getline+12635: mov%edx,%ebx
0x805623d getline+12637: mov0xee7c(%ebp),%edx
0x8056243 getline+12643: lea0xee90(%ebp,%edx,4),%edi
(gdb) i f
Stack level 0, frame at 0xbfbfcc10:
eip = 0x805622c in getline; saved eip 0x805047b
called by frame at 0xbfbfcc14
Arglist at 0xbfbfcc08, args:
Locals at 0xbfbfcc08, Previous frame's sp is 0xbfbfcc10
Saved registers:
ebx at 0xbfbfcbfc, ebp at 0xbfbfcc08, esi at 0xbfbfcc00, edi at
0xbfbfcc04,
eip at 0xbfbfcc0c
(gdb)
Testing program:
---snip---
#include glob.h
#include stdio.h
#define MAXUSRARGS 100
#define MAXGLOBARGS 1000
void do_glob() {
glob_t gl;
char **pop;
char buffer[256];
strcpy(buffer, {A*/../A*/../A*/../A*/../A*/../A*/../A*});
int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_TILDE;
memset(gl, 0, sizeof(gl));
gl.gl_matchc = MAXGLOBARGS;
flags |= GLOB_LIMIT;
if (glob(buffer, flags, NULL, gl)) {
printf(GLOB FAILED!\n);
return 0;
}
else
I want to submit a solution to solve a bug
Hello, I found the solution about why this bug occurs. http://www.freebsd.org/cgi/query-pr.cgi?pr=125239cat= I would like to contribute my knowledge to FreeBSD website but do not know where to start. Can you let me know what's the next step if I want to submit a solution? Thank, -- Jeff Mo Santa Clara University Linux+, SCJP, SCWCD, MCSD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: I want to submit a solution to solve a bug
On Wed, Feb 17, 2010 at 6:20 PM, Jeff Mo mo0...@gmail.com wrote: Hello, I found the solution about why this bug occurs. http://www.freebsd.org/cgi/query-pr.cgi?pr=125239cat= Make use of Submit Followup link. I would like to contribute my knowledge to FreeBSD website but do not know where to start. Can you let me know what's the next step if I want to submit a solution? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
NDISulator bug on amd64
On 1/16/10, Paul B Mahol one...@gmail.com wrote: On 1/11/10, Paul B Mahol one...@gmail.com wrote: On 1/11/10, Bob Johnson fbsdli...@gmail.com wrote: On 1/9/10, Paul B Mahol one...@gmail.com wrote: On 12/16/09, Bob Johnson fbsdli...@gmail.com wrote: I'm using an ExpressCard for wireless networking because there seems to be no driver for the internal card in my laptop (and NDIS panics the system). The Expresscard shows up as a PCI device and works fine, How are you using NDIS and when system panic what is displayed? I tried to use ndisgen with the internal Dell 1397 card. I don't have details available right now, although if you need them I can try it again. When I did the kldload the system spit out error messages about unknown symbols and then panic-ed. I did some searching of the archives and found a message describing the same symptoms, and the response posted was that it indicated that the Windows driver made API calls that were not implemented in the NDIS wrapper. This was a 64-bit Windows driver and an amd64 FreeBSD system. Similar results in both FreeBSD 7.2 and 8.0. It appears that kern/132672 is describing the same or a very similar issue. It also suggests that there is a more fundamental problem than the unrecognized symbols. I can try to reproduce the problem tonight if you want me to. Thanks, If you have debug kernel, then make breakpoint for MSCALL2 (kldload ndis.ko before that): `break MSCALL2' Should be `break w86_64_call2' Then load ndisgen module. Then single step it with `s' it should panic after few steps. At least this is issue I'm experiencing on amd64, it fails in DriverEntry(). with the same virtual address as in kern/132672. I fixed bug that caused panic on amd64 in DriverEntry(). Code is available from here: www.gitorious.org/NDISulator ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re[2]: BUG setfib
Здравствуйте, Ihor. Вы писали 4 января 2010 г., 20:44:18: IP Коньков Евгений wrote: Здравствуйте, Freebsd-questions. kes# setfib 1 get_last.pl setfib: get_last.pl: No such file or directory kes# pwd /usr/home/kes/ Для продолжения нажмите любую клавишу... kes# setfib -1 /usr/home/kes/get_last.pl run is OK! setfib must use current directory to run programm or at least must supply option to ON/OFF this behavior IP why do you think setfib MUST be such an exception? IP you can do setfib 1 ./bla.pl or tweak your PATH so I can run: kes# setfib -c -1 get_last.pl You are right. I miss that %-( Thank you -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: spamassassin Y2010 bug
Matthew Seaman wrote: I'll add your patches and post an updated shar later on. Done. Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
BUG setfib
Здравствуйте, Freebsd-questions. kes# setfib 1 get_last.pl setfib: get_last.pl: No such file or directory kes# pwd /usr/home/kes/ Для продолжения нажмите любую клавишу... kes# setfib -1 /usr/home/kes/get_last.pl run is OK! setfib must use current directory to run programm or at least must supply option to ON/OFF this behavior so I can run: kes# setfib -c -1 get_last.pl -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: BUG setfib
On Mon, Jan 04, 2010 at 08:29:53PM +0200, Коньков Евгений wrote: Здравствуйте, Freebsd-questions. kes# setfib 1 get_last.pl setfib: get_last.pl: No such file or directory kes# pwd /usr/home/kes/ Для продолжения нажмите любую клавишу... kes# setfib -1 /usr/home/kes/get_last.pl run is OK! setfib must use current directory to run programm or at least must supply option to ON/OFF this behavior so I can run: kes# setfib -c -1 get_last.pl -- С уважением, Коньков mailto:kes-...@yandex.ru From setfib(1) manpage: ENVIRONMENT The PATH environment variable is used to locate the requested utility if the name contains no `/' characters. So behaviour you are seeing is correct. HTH, Yuri ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: BUG setfib
Коньков Евгений wrote: Здравствуйте, Freebsd-questions. kes# setfib 1 get_last.pl setfib: get_last.pl: No such file or directory kes# pwd /usr/home/kes/ Для продолжения нажмите любую клавишу... kes# setfib -1 /usr/home/kes/get_last.pl run is OK! setfib must use current directory to run programm or at least must supply option to ON/OFF this behavior why do you think setfib MUST be such an exception? you can do setfib 1 ./bla.pl or tweak your PATH so I can run: kes# setfib -c -1 get_last.pl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: spamassassin Y2010 bug
Jeffrey Goldberg wrote: Alternatively, if someone were sufficiently motived they could put together an SA utilities port that installs a number of maintenance scripts which a user can enable. This sounds like a very good idea to me. As far as I can see, there's only one script required, which can be based on Jeremy's one in ports/127242 but extended so that: * allow various flags to be passed to sa-update - alternative update channels - extra GPG keys - gpghomedir setting * sa-compile can optionally be run if any updates are downloaded This should be installed as a daily periodic script -- which should be appropriate for most users: anyone wanting more frequent updates can just run it stand-alone as a cron job. Anything else? Jeremy -- any objections to my stealing your script as the basis of this? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
spamassassin - Y2K10 bug
There is an apparent bug in 'spamassassin' regarding 2010 e-mails. The full story is available here: http://spamassassin.apache.org/. There is also a discussion of it on SlashDot: http://it.slashdot.org/story/10/01/02/0027207/SpamAssassin-2010-Bug -- Jerry ges...@yahoo.com |=== |=== |=== |=== | Just saying no prevents teenage pregnancy the way Have a nice day cures chronic depression. Faye Wattleton http://en.wikipedia.org/wiki/Faye_Wattleton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: spamassassin - Y2K10 bug
On Sun, 3 Jan 2010 06:19:55 -0500 Jerry ges...@yahoo.com wrote: There is an apparent bug in 'spamassassin' regarding 2010 e-mails. The full story is available here: http://spamassassin.apache.org/. There is also a discussion of it on SlashDot: http://it.slashdot.org/story/10/01/02/0027207/SpamAssassin-2010-Bug And it was discussed on this list a few threads back. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: spamassassin Y2010 bug
Matthew Seaman wrote: Jeffrey Goldberg wrote: Alternatively, if someone were sufficiently motived they could put together an SA utilities port that installs a number of maintenance scripts which a user can enable. This sounds like a very good idea to me. As far as I can see, there's only one script required, which can be based on Jeremy's one in ports/127242 but extended so that: * allow various flags to be passed to sa-update - alternative update channels - extra GPG keys - gpghomedir setting * sa-compile can optionally be run if any updates are downloaded This should be installed as a daily periodic script -- which should be appropriate for most users: anyone wanting more frequent updates can just run it stand-alone as a cron job. Anything else? Jeremy -- any objections to my stealing your script as the basis of this? There's a .shar of the new port at: http://www.infracaninophile.co.uk/sa-utils.shar MD5 (sa-utils.shar) = aa1f75d840e97c4759119bf653d292bf SHA256 (sa-utils.shar) = 701d366035a6ff8dedfd33dfe9057bf33f94efd5f8263445561db1e9e98bcfd1 Comments, critique are welcome. Unless there are any killer bugs, I'll send-pr(1) in a week or so. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: spamassassin Y2010 bug
On Jan 3, 2010, at 2:10 PM, Matthew Seaman wrote: There's a .shar of the new port at: http://www.infracaninophile.co.uk/sa-utils.shar Comments, critique are welcome. Unless there are any killer bugs, I'll send-pr(1) in a week or so. Thanks for doing that. It looks great to me. I just wonder about it being enabled by default. I don't know what official policy is (if such a thing exists), but my experience with FreeBSD ports is that while they install things, the user must still explicitly enable them. So if might be a good idea to set the defaults to NO and include a pkg-message that instructs people to add the enabling lines in /etc/periodic.conf.local I'm also wondering about the name of the port. This really is only one utility. Anyway, those are trivial concerns. The substance of your port all looks very good to me. Cheers, -j -- Jeffrey Goldberghttp://www.goldmark.org/jeff/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: spamassassin Y2010 bug
On Sun, 03 Jan 2010 20:10:19 +
Matthew Seaman m.sea...@infracaninophile.co.uk wrote:
Comments, critique are welcome. Unless there are any killer bugs,
I'll send-pr(1) in a week or so.
You have:
: ${daily_sa_compile=YES}
sa-compile is installed by the SA port, but it requires devel/re2c,
which is an optional dependency. With a standard install your script
will update the rules, the compile will unconditionally fail, and so
spamd won't get restarted.
You could detect the re2c port, but I think it would be better to turn
it off by default
I'd also suggest running sa-compile with nice by default.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: spamassassin Y2010 bug
On Sun, 03 Jan 2010 20:10:19 +
Matthew Seaman m.sea...@infracaninophile.co.uk wrote:
Comments, critique are welcome. Unless there are any killer bugs,
I'll send-pr(1) in a week or so.
You have:
: ${daily_sa_compile=YES}
sa-compile is installed by the SA port, but it requires devel/re2c,
which is an optional dependency. With a standard install your script
will update the rules, the compile will unconditionally fail, and so
spamd won't get restarted.
You could detect the re2c port, but I think it would be better to turn
it off by default
I'd also suggest running sa-compile with nice by default.
I've put up a set of diffs (patches) in shar format that address some of
these issues:
1) re2c is listed as a run dependency. No two ways around it - if you do
plan on running sa-compile at some time, you'll need re2c, and chances are
that the machine that is running sa-update is also going to be running
sa-compile.
2) sa-compile is nice(1)'d by default, and you can provide other flags to
nice(1) as well.
See http://www.gsicomp.on.ca/~matt/sa-utils-patches.shar
Regards,
--
Matt Emmerton
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
