From onemda at gmail.com Sun Nov 1 16:02:59 2009 From: onemda at gmail.com (Paul B Mahol) Date: Sun Nov 1 16:03:11 2009 Subject: hostapd "deauthenticated due to local deauth request" In-Reply-To: <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> References: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> Message-ID: <3a142e750911010802l1a4183edh9d92eabdc21ab661@mail.gmail.com> On 10/31/09, Paul B Mahol wrote: > On 10/31/09, Ivan Voras wrote: >> I'm trying to setup an AP with a run0 interface on latest 8-STABLE but >> apparently 802.11 association fails: >> >> Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: associated >> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deauthenticated due to local deauth request >> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deassociated >> Oct 31 16:21:35 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: associated >> Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deauthenticated due to local deauth request >> Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >> 802.11: deassociated >> >> etc. Apparently the client never comes to the phase to receive DHCP >> address. >> >> The client in this case is WinXP and the setup did work with 7-STABLE, >> though with a bug in the rum driver which caused regular kernel panics >> on the AP. >> > > I tried same one with rum(4) as AP and ndis(4) as client on same > machine(some version of 8.0 - CURRENT). ndis client (configured via > wpa_supplicant) > would keep auth and deauth all the time. > I came to conclusion that rum is broken. But I think I remmember that > bwi(4) (as a client) > did not have such problem ... (I will test again to see) Well, I tried again and I got similar output like yours if I use wrong password. And with correct password client reauth all the time, maybe I need to setup ndis_events(8) .... From stylinae at email.uc.edu Sun Nov 1 19:29:31 2009 From: stylinae at email.uc.edu (Adam Stylinski) Date: Sun Nov 1 20:03:10 2009 Subject: Funny bug in zfs-snapshot-mgmt Message-ID: <96af083b0911011107q3a5215cci7ff5d568b5978d43@mail.gmail.com> So I'm not entirely sure which mailing list to post this to in order to inform the port/package maintainer, and this bug may already be fixed, as I'm using a package from 7.2-release, but I found a pretty interesting bug. I live in one of the regions of the US that actually are affected by Daylight Savings Time, and cron appears to have informed me when naming a snapshot that there is a duplicate (for obvious reasons): cannot create snapshot 'share/dadshare@auto-2009-11- 01_01.00': dataset already exists no snapshots were created Perhaps there is a way to use the tzdata distributed with freebsd to rename this snapshot? From stylinae at mail.uc.edu Sun Nov 1 20:08:51 2009 From: stylinae at mail.uc.edu (Stylinski, Adam (stylinae)) Date: Sun Nov 1 20:08:58 2009 Subject: Funny bug in ZFS-snapshot-mgmt Message-ID: <2EB0D8A0503880449C6D4F128879B50D01C1B8@BL2PRD0102MB030.prod.exchangelabs.com> So I'm not entirely sure which mailing list to post this to in order to inform the port/package maintainer, and this bug may already be fixed, as I'm using a package from 7.2-release, but I found a pretty interesting bug. I live in one of the regions of the US that actually are affected by Daylight Savings Time, and cron appears to have informed me when naming a snapshot that there is a duplicate (for obvious reasons): cannot create snapshot 'share/dadshare@auto-2009-11- 01_01.00': dataset already exists no snapshots were created Perhaps there is a way to use the tzdata distributed with freebsd to rename this snapshot? From tinderbox at freebsd.org Sun Nov 1 21:03:58 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 1 21:04:35 2009 Subject: [releng_8 tinderbox] failure on i386/i386 Message-ID: <200911012201.nA1M1kWK034186@freebsd-current.sentex.ca> TB --- 2009-11-01 21:50:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-01 21:50:22 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2009-11-01 21:50:22 - cleaning the object tree TB --- 2009-11-01 21:50:39 - cvsupping the source tree TB --- 2009-11-01 21:50:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2009-11-01 21:51:11 - building world TB --- 2009-11-01 21:51:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-01 21:51:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-01 21:51:11 - TARGET=i386 TB --- 2009-11-01 21:51:11 - TARGET_ARCH=i386 TB --- 2009-11-01 21:51:11 - TZ=UTC TB --- 2009-11-01 21:51:11 - __MAKE_CONF=/dev/null TB --- 2009-11-01 21:51:11 - cd /src TB --- 2009-11-01 21:51:11 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 1 21:51:12 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/i386/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/i386/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c building static c library ranlib libc.a cat /src/lib/libc/i386/Symbol.map /src/lib/libc/db/Symbol.map /src/lib/libc/compat-43/Symbol.map /src/lib/libc/gdtoa/Symbol.map /src/lib/libc/gen/Symbol.map /src/lib/libc/gmon/Symbol.map /src/lib/libc/inet/Symbol.map /src/lib/libc/locale/Symbol.map /src/lib/libc/nameser/Symbol.map /src/lib/libc/net/Symbol.map /src/lib/libc/nls/Symbol.map /src/lib/libc/posix1e/Symbol.map /src/lib/libc/quad/Symbol.map /src/lib/libc/regex/Symbol.map /src/lib/libc/resolv/Symbol.map /src/lib/libc/stdio/Symbol.map /src/lib/libc/stdlib/Symbol.map /src/lib/libc/stdtime/Symbol.map /src/lib/libc/string/Symbol.map /src/lib/libc/sys/Symbol.map /src/lib/libc/rpc/Symbol.map /src/lib/libc/uuid/Symbol.map /src/lib/libc/xdr/Symbol.map /src/lib/libc/yp/Symbol.map | cpp - - | awk -v vfile=/src/lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map File , line 514: Undefined library version `FBSD_1.2'. File , line 515: Symbol `getpagesizes' outside version scope. 2 error(s) total. *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-01 22:01:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-01 22:01:46 - ERROR: failed to build world TB --- 2009-11-01 22:01:46 - 484.61 user 90.03 system 684.37 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From tinderbox at freebsd.org Sun Nov 1 21:15:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 1 21:15:30 2009 Subject: [releng_8 tinderbox] failure on i386/pc98 Message-ID: <200911012213.nA1MD8CU022907@freebsd-current.sentex.ca> TB --- 2009-11-01 22:01:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-01 22:01:47 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2009-11-01 22:01:47 - cleaning the object tree TB --- 2009-11-01 22:02:03 - cvsupping the source tree TB --- 2009-11-01 22:02:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2009-11-01 22:02:33 - building world TB --- 2009-11-01 22:02:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-01 22:02:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-01 22:02:33 - TARGET=pc98 TB --- 2009-11-01 22:02:33 - TARGET_ARCH=i386 TB --- 2009-11-01 22:02:33 - TZ=UTC TB --- 2009-11-01 22:02:33 - __MAKE_CONF=/dev/null TB --- 2009-11-01 22:02:33 - cd /src TB --- 2009-11-01 22:02:33 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 1 22:02:33 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c building static c library ranlib libc.a cat /src/lib/libc/i386/Symbol.map /src/lib/libc/db/Symbol.map /src/lib/libc/compat-43/Symbol.map /src/lib/libc/gdtoa/Symbol.map /src/lib/libc/gen/Symbol.map /src/lib/libc/gmon/Symbol.map /src/lib/libc/inet/Symbol.map /src/lib/libc/locale/Symbol.map /src/lib/libc/nameser/Symbol.map /src/lib/libc/net/Symbol.map /src/lib/libc/nls/Symbol.map /src/lib/libc/posix1e/Symbol.map /src/lib/libc/quad/Symbol.map /src/lib/libc/regex/Symbol.map /src/lib/libc/resolv/Symbol.map /src/lib/libc/stdio/Symbol.map /src/lib/libc/stdlib/Symbol.map /src/lib/libc/stdtime/Symbol.map /src/lib/libc/string/Symbol.map /src/lib/libc/sys/Symbol.map /src/lib/libc/rpc/Symbol.map /src/lib/libc/uuid/Symbol.map /src/lib/libc/xdr/Symbol.map /src/lib/libc/yp/Symbol.map | cpp - - | awk -v vfile=/src/lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map File , line 514: Undefined library version `FBSD_1.2'. File , line 515: Symbol `getpagesizes' outside version scope. 2 error(s) total. *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-01 22:13:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-01 22:13:08 - ERROR: failed to build world TB --- 2009-11-01 22:13:08 - 483.41 user 90.70 system 681.63 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From tinderbox at freebsd.org Sun Nov 1 21:23:01 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 1 21:23:19 2009 Subject: [releng_8 tinderbox] failure on ia64/ia64 Message-ID: <200911012220.nA1MKiFl089533@freebsd-current.sentex.ca> TB --- 2009-11-01 22:09:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-01 22:09:44 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2009-11-01 22:09:44 - cleaning the object tree TB --- 2009-11-01 22:10:01 - cvsupping the source tree TB --- 2009-11-01 22:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2009-11-01 22:10:35 - building world TB --- 2009-11-01 22:10:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-01 22:10:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-01 22:10:35 - TARGET=ia64 TB --- 2009-11-01 22:10:35 - TARGET_ARCH=ia64 TB --- 2009-11-01 22:10:35 - TZ=UTC TB --- 2009-11-01 22:10:35 - __MAKE_CONF=/dev/null TB --- 2009-11-01 22:10:35 - cd /src TB --- 2009-11-01 22:10:35 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 1 22:10:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c building static c library ranlib libc.a cat /src/lib/libc/ia64/Symbol.map /src/lib/libc/db/Symbol.map /src/lib/libc/compat-43/Symbol.map /src/lib/libc/gdtoa/Symbol.map /src/lib/libc/gen/Symbol.map /src/lib/libc/gmon/Symbol.map /src/lib/libc/inet/Symbol.map /src/lib/libc/locale/Symbol.map /src/lib/libc/nameser/Symbol.map /src/lib/libc/net/Symbol.map /src/lib/libc/nls/Symbol.map /src/lib/libc/posix1e/Symbol.map /src/lib/libc/regex/Symbol.map /src/lib/libc/resolv/Symbol.map /src/lib/libc/stdio/Symbol.map /src/lib/libc/stdlib/Symbol.map /src/lib/libc/stdtime/Symbol.map /src/lib/libc/string/Symbol.map /src/lib/libc/sys/Symbol.map /src/lib/libc/rpc/Symbol.map /src/lib/libc/uuid/Symbol.map /src/lib/libc/xdr/Symbol.map /src/lib/libc/yp/Symbol.map | cpp - - | awk -v vfile=/src/lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map File , line 515: Undefined library version `FBSD_1.2'. File , line 516: Symbol `getpagesizes' outside version scope. 2 error(s) total. *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-01 22:20:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-01 22:20:44 - ERROR: failed to build world TB --- 2009-11-01 22:20:44 - 470.88 user 88.46 system 660.02 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From tinderbox at freebsd.org Sun Nov 1 21:25:34 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 1 21:25:40 2009 Subject: [releng_8 tinderbox] failure on mips/mips Message-ID: <200911012223.nA1MNGVX024269@freebsd-current.sentex.ca> TB --- 2009-11-01 22:13:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-01 22:13:08 - starting RELENG_8 tinderbox run for mips/mips TB --- 2009-11-01 22:13:08 - cleaning the object tree TB --- 2009-11-01 22:13:18 - cvsupping the source tree TB --- 2009-11-01 22:13:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2009-11-01 22:13:48 - building world TB --- 2009-11-01 22:13:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-01 22:13:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-01 22:13:48 - TARGET=mips TB --- 2009-11-01 22:13:48 - TARGET_ARCH=mips TB --- 2009-11-01 22:13:48 - TZ=UTC TB --- 2009-11-01 22:13:48 - __MAKE_CONF=/dev/null TB --- 2009-11-01 22:13:48 - cd /src TB --- 2009-11-01 22:13:48 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 1 22:13:49 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c building static c library ranlib libc.a cat /src/lib/libc/mips/Symbol.map /src/lib/libc/db/Symbol.map /src/lib/libc/compat-43/Symbol.map /src/lib/libc/gdtoa/Symbol.map /src/lib/libc/gen/Symbol.map /src/lib/libc/gmon/Symbol.map /src/lib/libc/inet/Symbol.map /src/lib/libc/locale/Symbol.map /src/lib/libc/nameser/Symbol.map /src/lib/libc/net/Symbol.map /src/lib/libc/nls/Symbol.map /src/lib/libc/posix1e/Symbol.map /src/lib/libc/quad/Symbol.map /src/lib/libc/regex/Symbol.map /src/lib/libc/resolv/Symbol.map /src/lib/libc/stdio/Symbol.map /src/lib/libc/stdlib/Symbol.map /src/lib/libc/stdtime/Symbol.map /src/lib/libc/string/Symbol.map /src/lib/libc/sys/Symbol.map /src/lib/libc/rpc/Symbol.map /src/lib/libc/uuid/Symbol.map /src/lib/libc/xdr/Symbol.map /src/lib/libc/yp/Symbol.map | cpp - - | awk -v vfile=/src/lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map File , line 507: Undefined library version `FBSD_1.2'. File , line 508: Symbol `getpagesizes' outside version scope. 2 error(s) total. *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-01 22:23:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-01 22:23:16 - ERROR: failed to build world TB --- 2009-11-01 22:23:16 - 437.46 user 84.12 system 608.02 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From tinderbox at freebsd.org Sun Nov 1 21:27:18 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 1 21:27:33 2009 Subject: [releng_8 tinderbox] failure on powerpc/powerpc Message-ID: <200911012225.nA1MP0Q2038398@freebsd-current.sentex.ca> TB --- 2009-11-01 22:14:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-01 22:14:11 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2009-11-01 22:14:11 - cleaning the object tree TB --- 2009-11-01 22:14:25 - cvsupping the source tree TB --- 2009-11-01 22:14:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2009-11-01 22:14:52 - building world TB --- 2009-11-01 22:14:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-01 22:14:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-01 22:14:52 - TARGET=powerpc TB --- 2009-11-01 22:14:52 - TARGET_ARCH=powerpc TB --- 2009-11-01 22:14:52 - TZ=UTC TB --- 2009-11-01 22:14:52 - __MAKE_CONF=/dev/null TB --- 2009-11-01 22:14:52 - cd /src TB --- 2009-11-01 22:14:52 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 1 22:14:53 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c building static c library ranlib libc.a cat /src/lib/libc/powerpc/Symbol.map /src/lib/libc/db/Symbol.map /src/lib/libc/compat-43/Symbol.map /src/lib/libc/gdtoa/Symbol.map /src/lib/libc/gen/Symbol.map /src/lib/libc/gmon/Symbol.map /src/lib/libc/inet/Symbol.map /src/lib/libc/locale/Symbol.map /src/lib/libc/nameser/Symbol.map /src/lib/libc/net/Symbol.map /src/lib/libc/nls/Symbol.map /src/lib/libc/posix1e/Symbol.map /src/lib/libc/quad/Symbol.map /src/lib/libc/regex/Symbol.map /src/lib/libc/resolv/Symbol.map /src/lib/libc/stdio/Symbol.map /src/lib/libc/stdlib/Symbol.map /src/lib/libc/stdtime/Symbol.map /src/lib/libc/string/Symbol.map /src/lib/libc/sys/Symbol.map /src/lib/libc/rpc/Symbol.map /src/lib/libc/uuid/Symbol.map /src/lib/libc/xdr/Symbol.map /src/lib/libc/yp/Symbol.map | cpp - - | awk -v vfile=/src/lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map File , line 502: Undefined library version `FBSD_1.2'. File , line 503: Symbol `getpagesizes' outside version scope. 2 error(s) total. *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-01 22:25:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-01 22:25:00 - ERROR: failed to build world TB --- 2009-11-01 22:25:00 - 476.10 user 89.70 system 648.99 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From tinderbox at freebsd.org Sun Nov 1 21:32:26 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Nov 1 21:32:44 2009 Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Message-ID: <200911012230.nA1MU7Nq053232@freebsd-current.sentex.ca> TB --- 2009-11-01 22:20:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-01 22:20:45 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2009-11-01 22:20:45 - cleaning the object tree TB --- 2009-11-01 22:20:58 - cvsupping the source tree TB --- 2009-11-01 22:20:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2009-11-01 22:21:37 - building world TB --- 2009-11-01 22:21:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-01 22:21:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-01 22:21:37 - TARGET=sparc64 TB --- 2009-11-01 22:21:37 - TARGET_ARCH=sparc64 TB --- 2009-11-01 22:21:37 - TZ=UTC TB --- 2009-11-01 22:21:37 - __MAKE_CONF=/dev/null TB --- 2009-11-01 22:21:37 - cd /src TB --- 2009-11-01 22:21:37 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 1 22:21:37 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c building static c library ranlib libc.a cat /src/lib/libc/sparc64/Symbol.map /src/lib/libc/db/Symbol.map /src/lib/libc/compat-43/Symbol.map /src/lib/libc/gdtoa/Symbol.map /src/lib/libc/gen/Symbol.map /src/lib/libc/gmon/Symbol.map /src/lib/libc/inet/Symbol.map /src/lib/libc/locale/Symbol.map /src/lib/libc/nameser/Symbol.map /src/lib/libc/net/Symbol.map /src/lib/libc/nls/Symbol.map /src/lib/libc/posix1e/Symbol.map /src/lib/libc/regex/Symbol.map /src/lib/libc/resolv/Symbol.map /src/lib/libc/stdio/Symbol.map /src/lib/libc/stdlib/Symbol.map /src/lib/libc/stdtime/Symbol.map /src/lib/libc/string/Symbol.map /src/lib/libc/sys/Symbol.map /src/lib/libc/rpc/Symbol.map /src/lib/libc/uuid/Symbol.map /src/lib/libc/xdr/Symbol.map /src/lib/libc/yp/Symbol.map | cpp - - | awk -v vfile=/src/lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map File , line 542: Undefined library version `FBSD_1.2'. File , line 543: Symbol `getpagesizes' outside version scope. 2 error(s) total. *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-01 22:30:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-01 22:30:07 - ERROR: failed to build world TB --- 2009-11-01 22:30:07 - 410.23 user 83.26 system 562.05 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From rmacklem at uoguelph.ca Sun Nov 1 22:10:03 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Nov 1 22:10:14 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: <20091029135239.GX841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> <20091029135239.GX841@twoquid.cs.ru.nl> Message-ID: On Thu, 29 Oct 2009, Olaf Seibert wrote: > > Thanks, it looks like it should do the trick. I can't try it before > monday, though. > Although I think the patch does avoid sending the request on the partially closed connection, it doesn't fix the "real problem", so I don't know if it is worth testing? I'm hoping that the "Help TCP Wizards..." thread I just started on freebsd-current comes up with something. At least I can reproduce the problem now. (For some reason, I have to reboot the Solaris10 server before the problem appears for me. I can't think why this matters, but that's networking for you:-) rick From ivoras at freebsd.org Sun Nov 1 22:20:33 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Nov 1 22:20:40 2009 Subject: hostapd "deauthenticated due to local deauth request" - possibly a rum(4) problem? In-Reply-To: <3a142e750911010802l1a4183edh9d92eabdc21ab661__46192.910653963$1257091427$gmane$org@mail.gmail.com> References: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> <3a142e750911010802l1a4183edh9d92eabdc21ab661__46192.910653963$1257091427$gmane$org@mail.gmail.com> Message-ID: Paul B Mahol wrote: > On 10/31/09, Paul B Mahol wrote: >> On 10/31/09, Ivan Voras wrote: >>> I'm trying to setup an AP with a run0 interface on latest 8-STABLE but >>> apparently 802.11 association fails: >>> >>> Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >>> 802.11: associated >>> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >>> 802.11: deauthenticated due to local deauth request >>> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >>> 802.11: deassociated >>> >>> etc. Apparently the client never comes to the phase to receive DHCP >>> address. >>> >>> The client in this case is WinXP and the setup did work with 7-STABLE, >>> though with a bug in the rum driver which caused regular kernel panics >>> on the AP. >>> >> I tried same one with rum(4) as AP and ndis(4) as client on same >> machine(some version of 8.0 - CURRENT). ndis client (configured via >> wpa_supplicant) >> would keep auth and deauth all the time. >> I came to conclusion that rum is broken. But I think I remmember that >> bwi(4) (as a client) >> did not have such problem ... (I will test again to see) > > Well, I tried again and I got similar output like yours if I use wrong > password. And with correct password client reauth all the time, maybe > I need to setup ndis_events(8) .... I Googled a bit and it looks like in the Linuxworld problems such as this appear to be caused at the driver level :( It seems the only improvement in rum(4) between 7-stable and 8-stable are that it doesn't promptly panic the kernel any more :) From marius at nuenneri.ch Sun Nov 1 23:08:06 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Sun Nov 1 23:08:13 2009 Subject: Funny bug in zfs-snapshot-mgmt In-Reply-To: <96af083b0911011107q3a5215cci7ff5d568b5978d43@mail.gmail.com> References: <96af083b0911011107q3a5215cci7ff5d568b5978d43@mail.gmail.com> Message-ID: On Sun, Nov 1, 2009 at 20:07, Adam Stylinski wrote: > So I'm not entirely sure which mailing list to post this to in order to > inform the port/package maintainer, and this bug may already be fixed, as > I'm using a package from 7.2-release, but I found a pretty interesting bug. > I live in one of the regions of the US that actually are affected by > Daylight Savings Time, and cron appears to have informed me when naming a > snapshot that there is a duplicate (for obvious reasons): > > cannot create snapshot 'share/dadshare@auto-2009-11- > 01_01.00': dataset already exists > no snapshots were created > > Perhaps there is a way to use the tzdata distributed with freebsd to rename > this snapshot? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Hi, I'm the current maintainer. This bug is not fixed. The simplest solution would be to use UTC times. Another to add the current timezone to the snapshot name. Both not really satisfying. I would just live on with that on mail per year until the nuisance of DST is finally removed from our lives ;) - Marius From tinderbox at freebsd.org Mon Nov 2 02:12:17 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Nov 2 02:12:35 2009 Subject: [releng_8_0 tinderbox] failure on i386/i386 Message-ID: <200911020308.nA238Y40010425@freebsd-current.sentex.ca> TB --- 2009-11-02 02:53:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-02 02:53:57 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2009-11-02 02:53:57 - cleaning the object tree TB --- 2009-11-02 02:54:26 - cvsupping the source tree TB --- 2009-11-02 02:54:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2009-11-02 02:59:53 - building world TB --- 2009-11-02 02:59:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-02 02:59:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-02 02:59:53 - TARGET=i386 TB --- 2009-11-02 02:59:53 - TARGET_ARCH=i386 TB --- 2009-11-02 02:59:53 - TZ=UTC TB --- 2009-11-02 02:59:53 - __MAKE_CONF=/dev/null TB --- 2009-11-02 02:59:53 - cd /src TB --- 2009-11-02 02:59:53 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 2 02:59:53 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes [...] ===> kerberos5/usr.bin/kpasswd (buildincludes) ===> kerberos5/usr.bin/krb5-config (buildincludes) ===> kerberos5/usr.bin/ksu (buildincludes) ===> kerberos5/usr.bin/verify_krb5_conf (buildincludes) ===> kerberos5/usr.sbin (buildincludes) ===> kerberos5/usr.sbin/kstash (buildincludes) ===> kerberos5/usr.sbin/ktutil (buildincludes) /libexec/ld-elf.so.1: Cannot open "/lib/libncurses.so.8" *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-02 03:08:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-02 03:08:34 - ERROR: failed to build world TB --- 2009-11-02 03:08:34 - 419.13 user 72.95 system 876.43 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-i386-i386.full From tinderbox at freebsd.org Mon Nov 2 02:13:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Nov 2 02:14:13 2009 Subject: [releng_8_0 tinderbox] failure on ia64/ia64 Message-ID: <200911020310.nA23A3M0042159@freebsd-current.sentex.ca> TB --- 2009-11-02 03:08:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-02 03:08:34 - starting RELENG_8_0 tinderbox run for ia64/ia64 TB --- 2009-11-02 03:08:34 - cleaning the object tree TB --- 2009-11-02 03:08:59 - cvsupping the source tree TB --- 2009-11-02 03:08:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/ia64/ia64/supfile TB --- 2009-11-02 03:09:11 - building world TB --- 2009-11-02 03:09:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-02 03:09:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-02 03:09:11 - TARGET=ia64 TB --- 2009-11-02 03:09:11 - TARGET_ARCH=ia64 TB --- 2009-11-02 03:09:11 - TZ=UTC TB --- 2009-11-02 03:09:11 - __MAKE_CONF=/dev/null TB --- 2009-11-02 03:09:11 - cd /src TB --- 2009-11-02 03:09:11 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 2 03:09:12 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] ===> share/doc/usd/title (cleandir) rm -f Title.ascii Title.ascii.gz Title.ps Title.ps.gz Title.html Title-*.html _stamp.extra ===> share/doc/usd/contents (cleandir) rm -f contents.ascii contents.ascii.gz contents.ps contents.ps.gz contents.html contents-*.html _stamp.extra ===> share/doc/usd/04.csh (cleandir) rm -f paper.ascii paper.ascii.gz paper.ps paper.ps.gz paper.html paper-*.html _stamp.extra ===> share/doc/usd/07.mail (cleandir) /usr/bin/make: Permission denied *** Error code 126 Stop in /src/share/doc/usd. *** Error code 1 Stop in /src/share/doc. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-02 03:10:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-02 03:10:03 - ERROR: failed to build world TB --- 2009-11-02 03:10:03 - 29.73 user 20.99 system 89.52 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-ia64-ia64.full From gnukix at alltel.blackberry.com Mon Nov 2 01:34:32 2009 From: gnukix at alltel.blackberry.com (gnukix@alltel.blackberry.com) Date: Mon Nov 2 03:15:55 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd Message-ID: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> I can send in more documentation later but I am seeing severe zfs performance issues with lighttpd. Same machine using UFS will push 1gbit or more but same content and traffic load can not hit 200mbit. Ufs does around 3 megabytes/sec IO at 800mbit network but zfs pushes the disks into the ground with 50+ megabytes/sec dusk i/o. No compression no atime no checksums on zfs and still same IO levels. Ufs with soft updates and atime on. Orders of magnitude more disk IO... Like zfs isn't using cache or isn't coalescing disk reads or both. Has anyone else seen this or have any recommendations? Lighttpd config remains exactly the same as well FYI. Only difference is ufs vs zfs. Sent from my BlackBerry Smartphone provided by Alltel From gerrit at pmp.uni-hannover.de Mon Nov 2 08:29:21 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Mon Nov 2 08:29:28 2009 Subject: zfs panic Message-ID: <20091102092915.71cdeef9.gerrit@pmp.uni-hannover.de> Hi, I got the following panic when rebooting after a crash on 7.2-REL: panic: solaris assert: dmu_read(os, smo->smo_object, offset, size, entry_map) == 0 (0x5 == 0x0), file: /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa ce_map.c, line: 341 This seems to be the same panic as mentioned here: . However, I did not see warnings about the ZIL. The crash leading to this situation was probably caused by me pushing the controller card a bit too hard (mechanically) during operation (well, so much about hot-plugging of cards :-). Since my pool was almost empty anyway and I needed the machine, I opted to recreate the pool instead of trying the patches supplied by pjd@ in the thread above. But nevertheless I would like to be prepared if this happens again (and the pool is not empty :-). Right now I am updating the system to 8.0-RC2. Will this issue go away with zpoolv13/FBSD8.0 (as suggested above)? I could not find out from the thread above if the suggested patches helped or if anything from this has been commited at all. Pawel or Daniel, do you remember what the final result was? cu Gerrit From ivoras at freebsd.org Mon Nov 2 09:52:58 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Nov 2 09:53:06 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> Message-ID: gnukix@alltel.blackberry.com wrote: > I can send in more documentation later but I am seeing severe zfs performance issues with lighttpd. Same machine using UFS will push 1gbit or more but same content and traffic load can not hit 200mbit. Ufs does around 3 megabytes/sec IO at 800mbit network but zfs pushes the disks into the ground with 50+ megabytes/sec dusk i/o. No compression no atime no checksums on zfs and still same IO levels. Ufs with soft updates and atime on. Orders of magnitude more disk IO... Like zfs isn't using cache or isn't coalescing disk reads or both. > > Has anyone else seen this or have any recommendations? Lighttpd config remains exactly the same as well FYI. Only difference is ufs vs zfs. AFAIK, ZFS is incompatible (currently) with some advanced VM operations (like mmap, and I think sendfile relies on the same mechanism as mmap), so that could be a cause of the slowdown. Though I'm surprised you can only get 200 MBit/s - that's 25 MB/s and I think that even with multiple memcpy-ing data around the kernel you should be able to get hundreds of MB/s on newer hardware (which normally really can achieve tens of gigabytes/s of sustained memory access). What else can you observe from your system? Do you have exceedingly high sys times and load numbers? I'm also interested in what does 10 seconds of running 'vmstat 1' looks like on your system. Is it a bare machine or a virtual machine? From tevans.uk at googlemail.com Mon Nov 2 09:53:32 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Mon Nov 2 09:54:00 2009 Subject: 8.0-RC1 ZFS loader extremely slow Message-ID: <2e027be00911020153j6b206e01td2b22a194a116565@mail.gmail.com> Hi all I just installed 8.0-RC1 amd64 on a 6 gpt disk ZFS raidz1 (following the guide on the wiki), but have problems on reboot with the newly installed ZFS aware loader. The loader runs correctly, but incredibly slowly. It takes about 2 hours to get to the point where it enumerates the BIOS disks, although when it gets to that point, it does not take a long time to enumerate each disk. It takes about 2 minutes for each character change of the spinner! Fully completing the loader takes somewhere between 2 and 8 hours (I got bored watching it), and works correctly. The loader from the memstick image works normally. Daichi GOTO experienced something similar back in January [1], but there didn't seem to be any resolution to that problem. Disabling AHCI has no effect. Interestingly, we both have P45 based motherboards. I will try installing 8.0-RC2 tonight, and try to save verbose boot logs, dmidecode etc. If there is any other information I should be looking at, please let me know. Cheers Tom [1] http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-02/msg00108.html From O.Seibert at cs.ru.nl Mon Nov 2 10:10:06 2009 From: O.Seibert at cs.ru.nl (Olaf Seibert) Date: Mon Nov 2 10:10:14 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: References: <20091027164159.GU841@twoquid.cs.ru.nl> <20091029135239.GX841@twoquid.cs.ru.nl> Message-ID: <20091102100958.GY841@twoquid.cs.ru.nl> On Sun 01 Nov 2009 at 17:17:15 -0500, Rick Macklem wrote: > On Thu, 29 Oct 2009, Olaf Seibert wrote: > > > > > Thanks, it looks like it should do the trick. I can't try it before > > monday, though. > > > Although I think the patch does avoid sending the request on the > partially closed connection, it doesn't fix the "real problem", > so I don't know if it is worth testing? Well, I tested it anyway, just in case. It seems to work fine for me, so far. I don't see your extra RSTs either. Maybe that is because in my case the client used a different port number for the new connection. (Usually, this is controlled by the TCP option SO_REUSEADDR from ). Here is a new packet trace. I had to cut out some packets since I forgot to kill some (failing) mount attempts of another directory on the same server. (sorry again for the long lines) No. Time Source Destination Protocol Info 486 60.438406 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 487), DH:0x61b8eb12/date 487 60.438629 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 486) Error:NFS3ERR_NOENT 488 60.538796 xxx.xxx.31.43 xxx.xxx.16.142 TCP hello-port > nfs [ACK] Seq=36477 Ack=44701 Win=8192 Len=0 TSV=228817 TSER=1575935 last real action on old connection (client port "hello-port") 537 420.437763 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > hello-port [FIN, ACK] Seq=44701 Ack=36477 Win=49232 Len=0 TSV=1611935 TSER=228817 538 420.437805 xxx.xxx.31.43 xxx.xxx.16.142 TCP hello-port > nfs [ACK] Seq=36477 Ack=44702 Win=8192 Len=0 TSV=588734 TSER=1611935 server ends connection 563 605.334262 xxx.xxx.31.43 xxx.xxx.16.142 TCP hello-port > nfs [FIN, ACK] Seq=36477 Ack=44702 Win=8192 Len=0 TSV=773641 TSER=1611935 some time later, client now ends connection before sending its request on new connection (port 875) 564 605.334303 xxx.xxx.31.43 xxx.xxx.16.142 TCP 875 > nfs [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=5 TSV=773641 TSER=0 565 605.334440 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > hello-port [ACK] Seq=44702 Ack=36478 Win=49232 Len=0 TSV=1630424 TSER=773641 566 605.334564 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 875 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSV=1630424 TSER=773641 MSS=1460 WS=0 567 605.334588 xxx.xxx.31.43 xxx.xxx.16.142 TCP 875 > nfs [ACK] Seq=1 Ack=1 Win=66592 Len=0 TSV=773641 TSER=1630424 new connection set up 568 605.334605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 570), FH:0x008002a2 569 605.334828 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 875 [ACK] Seq=1 Ack=141 Win=49092 Len=0 TSV=1630424 TSER=773641 and in use > I'm hoping that the "Help TCP Wizards..." thread I just started > on freebsd-current comes up with something. > > At least I can reproduce the problem now. (For some reason, I have > to reboot the Solaris10 server before the problem appears for me. > I can't think why this matters, but that's networking for you:-) Maybe it depends on server load or something. This particular server is a central file server at a university, it may have some more pressure to terminate unused connections. > rick -Olaf. -- From 000.fbsd at quip.cz Mon Nov 2 11:06:55 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon Nov 2 11:08:16 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> Message-ID: <4AEEBD4B.1050407@quip.cz> Ivan Voras wrote: > gnukix@alltel.blackberry.com wrote: >> I can send in more documentation later but I am seeing severe zfs >> performance issues with lighttpd. Same machine using UFS will push >> 1gbit or more but same content and traffic load can not hit 200mbit. >> Ufs does around 3 megabytes/sec IO at 800mbit network but zfs pushes >> the disks into the ground with 50+ megabytes/sec dusk i/o. No >> compression no atime no checksums on zfs and still same IO levels. Ufs >> with soft updates and atime on. Orders of magnitude more disk IO... >> Like zfs isn't using cache or isn't coalescing disk reads or both. >> Has anyone else seen this or have any recommendations? Lighttpd config >> remains exactly the same as well FYI. Only difference is ufs vs zfs. > > AFAIK, ZFS is incompatible (currently) with some advanced VM operations > (like mmap, and I think sendfile relies on the same mechanism as mmap), > so that could be a cause of the slowdown. Though I'm surprised you can > only get 200 MBit/s - that's 25 MB/s and I think that even with multiple > memcpy-ing data around the kernel you should be able to get hundreds of > MB/s on newer hardware (which normally really can achieve tens of > gigabytes/s of sustained memory access). I have more strange issue with Lighttpd in jail on top of ZFS. Lighttpd is serving static content (mp3 downloads thru flash player). Is runs fine for relatively small number of parallel clients with bandwidth about 30 Mbps, but after some number of clients is reached (about 50-60 parallel clients) the throughput drops down to 6 Mbps. I can server hundereds of clients on same HW using Lighttpd not in jail and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe more). I don't know if it is ZFS or Jail issue. Miroslav Lachman From ivoras at freebsd.org Mon Nov 2 11:55:58 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Nov 2 11:56:05 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <4AEEBD4B.1050407@quip.cz> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> Message-ID: Miroslav Lachman wrote: > Ivan Voras wrote: >> gnukix@alltel.blackberry.com wrote: >>> I can send in more documentation later but I am seeing severe zfs >>> performance issues with lighttpd. Same machine using UFS will push >>> 1gbit or more but same content and traffic load can not hit 200mbit. >>> Ufs does around 3 megabytes/sec IO at 800mbit network but zfs pushes >>> the disks into the ground with 50+ megabytes/sec dusk i/o. No >>> compression no atime no checksums on zfs and still same IO levels. Ufs >>> with soft updates and atime on. Orders of magnitude more disk IO... >>> Like zfs isn't using cache or isn't coalescing disk reads or both. >>> Has anyone else seen this or have any recommendations? Lighttpd config >>> remains exactly the same as well FYI. Only difference is ufs vs zfs. >> >> AFAIK, ZFS is incompatible (currently) with some advanced VM operations >> (like mmap, and I think sendfile relies on the same mechanism as mmap), >> so that could be a cause of the slowdown. Though I'm surprised you can >> only get 200 MBit/s - that's 25 MB/s and I think that even with multiple >> memcpy-ing data around the kernel you should be able to get hundreds of >> MB/s on newer hardware (which normally really can achieve tens of >> gigabytes/s of sustained memory access). > > I have more strange issue with Lighttpd in jail on top of ZFS. Lighttpd > is serving static content (mp3 downloads thru flash player). Is runs > fine for relatively small number of parallel clients with bandwidth > about 30 Mbps, but after some number of clients is reached (about 50-60 > parallel clients) the throughput drops down to 6 Mbps. > > I can server hundereds of clients on same HW using Lighttpd not in jail > and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe more). > > I don't know if it is ZFS or Jail issue. Do you have actual disk IO or is the vast majority of your data served from the caches? (actually - the same question to the OP) From 000.fbsd at quip.cz Mon Nov 2 13:14:39 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon Nov 2 13:14:47 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> Message-ID: <4AEEDB3B.5020600@quip.cz> Ivan Voras wrote: > Miroslav Lachman wrote: [..] >> I have more strange issue with Lighttpd in jail on top of ZFS. >> Lighttpd is serving static content (mp3 downloads thru flash player). >> Is runs fine for relatively small number of parallel clients with >> bandwidth about 30 Mbps, but after some number of clients is reached >> (about 50-60 parallel clients) the throughput drops down to 6 Mbps. >> >> I can server hundereds of clients on same HW using Lighttpd not in >> jail and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe >> more). >> >> I don't know if it is ZFS or Jail issue. > > Do you have actual disk IO or is the vast majority of your data served > from the caches? (actually - the same question to the OP) I had ZFS zpool as mirror of two SATA II drives (500GB) and in the peak iostat (or systat -vm or gstat) shows about 80 tps / 60% busy. In case of UFS, I am using gmirrored 1TB SATA II drives working nice with 160 or more tps. Both setups are using FreeBSD 7.x amd64 with GENERIC kernel, 4GB of RAM. As the ZFS + Lighttpd in jail was unreliable, I am no longer using it, but if you want some more info for debuging, I can set it up again. Miroslav Lachman From ivoras at freebsd.org Mon Nov 2 13:39:28 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Nov 2 13:39:35 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <4AEEDB3B.5020600@quip.cz> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> Message-ID: Miroslav Lachman wrote: > Ivan Voras wrote: >> Miroslav Lachman wrote: > > [..] > >>> I have more strange issue with Lighttpd in jail on top of ZFS. >>> Lighttpd is serving static content (mp3 downloads thru flash player). >>> Is runs fine for relatively small number of parallel clients with >>> bandwidth about 30 Mbps, but after some number of clients is reached >>> (about 50-60 parallel clients) the throughput drops down to 6 Mbps. >>> >>> I can server hundereds of clients on same HW using Lighttpd not in >>> jail and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe >>> more). >>> >>> I don't know if it is ZFS or Jail issue. >> >> Do you have actual disk IO or is the vast majority of your data served >> from the caches? (actually - the same question to the OP) > > I had ZFS zpool as mirror of two SATA II drives (500GB) and in the peak > iostat (or systat -vm or gstat) shows about 80 tps / 60% busy. > > In case of UFS, I am using gmirrored 1TB SATA II drives working nice > with 160 or more tps. > > Both setups are using FreeBSD 7.x amd64 with GENERIC kernel, 4GB of RAM. > > As the ZFS + Lighttpd in jail was unreliable, I am no longer using it, > but if you want some more info for debuging, I can set it up again. For what it's worth, I have just set up a little test on a production machine with 3 500 GB SATA drives in RAIDZ, FreeBSD 7.2-RELEASE. The total data set is some 2 GB in 5000 files but the machine has only 2 GB RAM total so there is some disk IO - about 40 IOPS per drive. I'm also using Apache-worker, not lighty, and siege to benchmark with 10 concurrent users. In this setup, the machine has no problems saturating a 100 Mbit/s link - it's not on a LAN but the latency is close enough and I get ~~ 11 MB/s. From rmacklem at uoguelph.ca Mon Nov 2 15:30:09 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Nov 2 15:30:16 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: <20091102100958.GY841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> <20091029135239.GX841@twoquid.cs.ru.nl> <20091102100958.GY841@twoquid.cs.ru.nl> Message-ID: On Mon, 2 Nov 2009, Olaf Seibert wrote: >> Although I think the patch does avoid sending the request on the >> partially closed connection, it doesn't fix the "real problem", >> so I don't know if it is worth testing? > > Well, I tested it anyway, just in case. It seems to work fine for me, so > far. > Yes, I think the patch is ok, but it doesn't completely resolve the reconnect issue. It's good to hear that it helps for your case. > I don't see your extra RSTs either. Maybe that is because in my case the > client used a different port number for the new connection. (Usually, > this is controlled by the TCP option SO_REUSEADDR from ). > For my packet trace, it is using different port#s. The problem is that, for some reason, it sends the RST from the new port# instead of the port# for the old connection just closed via soclose(). I don't know why you don't see the extra RSTs, but consider yourself lucky, since you should be ok without them. (It may simply be that your server isn't Solaris10 --> a different TCP stack in it.) Do you happen to know what your server is? >> I'm hoping that the "Help TCP Wizards..." thread I just started >> on freebsd-current comes up with something. >> >> At least I can reproduce the problem now. (For some reason, I have >> to reboot the Solaris10 server before the problem appears for me. >> I can't think why this matters, but that's networking for you:-) > > Maybe it depends on server load or something. This particular server is > a central file server at a university, it may have some more pressure to > terminate unused connections. > Or type of server (ie. not Solaris10). It definitely depends upon timing in the client. (I'm about to try introducing a 1sec delay before the soconnect() call and see if that makes the RSTs go away. Not much of a fix, but...) I now recall that I ran into a similar problem (although I didn't dig into the packet traces then) when testing my Mac OS X 10 client, which uses essentially the reconnect code from Mac OS X 10.4 Tiger. I "fixed" it by adding a 1sec delay before the reconnect. Thanks for helping with testing, rick From npapke at acm.org Mon Nov 2 16:45:46 2009 From: npapke at acm.org (Norbert Papke) Date: Mon Nov 2 16:45:59 2009 Subject: 7.2 Stable Crash - possibly related to if_re In-Reply-To: <20091031212107.GC17243@michelle.cdnetworks.com> References: <200910292156.19845.npapke@acm.org> <200910301823.51274.npapke@acm.org> <20091031212107.GC17243@michelle.cdnetworks.com> Message-ID: <200911020830.44343.npapke@acm.org> On October 31, 2009, Pyun YongHyeon wrote: > On Fri, Oct 30, 2009 at 06:23:51PM -0700, Norbert Papke wrote: > > On October 30, 2009, Pyun YongHyeon wrote: > > > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > > > This occurred shortly after "scp"ing from a VirtualBox VM to the > > > > host. The file transfer got stuck. The "re" interface stopped > > > > working. Shortly afterwards, the host crashed. The "re" interface > > > > was used by the host, the guest was using a different NIC in bridged > > > > mode. > > > > > > > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct > > > > 29 18:36:57 PDT 2009 > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 0; apic id = 00 > > > > fault virtual address = 0x18 > > > > > > It looks like a NULL pointer dereference, possibly mbuf related > > > one. > > > > > > > fault code = supervisor write data, page not present > > > > instruction pointer = 0x8:0xffffffff80d476ee > > > > stack pointer = 0x10:0xffffff8000078ae0 > > > > frame pointer = 0x10:0xffffff8000078b40 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 18 (swi5: +) > > > > Physical memory: 8177 MB > > > > > > > By chance, did you stop the re0 interface with ifconfig when you > > > noticed the file transfer got stuck? > > > > It is possible. I had it happen twice. The first time I definitely > > tried to "down" re. I cannot recall what I did the second time. The > > crash dump is from the second time. > > Ok, then would you try attached patch? I have been running with patch for a couple of days now. Although I can still reproduce the problem with the file transfer, I have not been able to reproduce the panic. The patch appears to do what it is supposed to do. I am going to continue to try to come up with a better test case for the original file transfer problem. I no longer suspect "re" as a cause. Thank you very much for your help. Cheers, -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From npapke at acm.org Mon Nov 2 16:45:46 2009 From: npapke at acm.org (Norbert Papke) Date: Mon Nov 2 16:45:59 2009 Subject: 7.2 Stable Crash - possibly related to if_re In-Reply-To: <20091031212107.GC17243@michelle.cdnetworks.com> References: <200910292156.19845.npapke@acm.org> <200910301823.51274.npapke@acm.org> <20091031212107.GC17243@michelle.cdnetworks.com> Message-ID: <200911020845.44042.npapke@acm.org> On October 31, 2009, Pyun YongHyeon wrote: > On Fri, Oct 30, 2009 at 06:23:51PM -0700, Norbert Papke wrote: > > On October 30, 2009, Pyun YongHyeon wrote: > > > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > > > This occurred shortly after "scp"ing from a VirtualBox VM to the > > > > host. The file transfer got stuck. The "re" interface stopped > > > > working. Shortly afterwards, the host crashed. The "re" interface > > > > was used by the host, the guest was using a different NIC in bridged > > > > mode. > > > > > > > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct > > > > 29 18:36:57 PDT 2009 > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 0; apic id = 00 > > > > fault virtual address = 0x18 > > > > > > It looks like a NULL pointer dereference, possibly mbuf related > > > one. > > > > > > > fault code = supervisor write data, page not present > > > > instruction pointer = 0x8:0xffffffff80d476ee > > > > stack pointer = 0x10:0xffffff8000078ae0 > > > > frame pointer = 0x10:0xffffff8000078b40 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 18 (swi5: +) > > > By chance, did you stop the re0 interface with ifconfig when you > > > noticed the file transfer got stuck? > > > > It is possible. I had it happen twice. The first time I definitely > > tried to "down" re. I cannot recall what I did the second time. The > > crash dump is from the second time. > > Ok, then would you try attached patch? I have been running with the patch for a couple of days. Although I can still reproduce the lock-up of the network stack, I have not been able to reproduce the panic. The patch does what it is supposed to do. I will continue to try to come up with a better test case for the file transfer problem. However, I no longer suspect "re" as a cause. Thank you very much for your help. Cheers, -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From pyunyh at gmail.com Mon Nov 2 18:36:43 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 2 18:36:55 2009 Subject: 7.2 Stable Crash - possibly related to if_re In-Reply-To: <200911020845.44042.npapke@acm.org> References: <200910292156.19845.npapke@acm.org> <200910301823.51274.npapke@acm.org> <20091031212107.GC17243@michelle.cdnetworks.com> <200911020845.44042.npapke@acm.org> Message-ID: <20091102183556.GA1256@michelle.cdnetworks.com> On Mon, Nov 02, 2009 at 08:45:43AM -0800, Norbert Papke wrote: > On October 31, 2009, Pyun YongHyeon wrote: > > On Fri, Oct 30, 2009 at 06:23:51PM -0700, Norbert Papke wrote: > > > On October 30, 2009, Pyun YongHyeon wrote: > > > > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > > > > This occurred shortly after "scp"ing from a VirtualBox VM to the > > > > > host. The file transfer got stuck. The "re" interface stopped > > > > > working. Shortly afterwards, the host crashed. The "re" interface > > > > > was used by the host, the guest was using a different NIC in bridged > > > > > mode. > > > > > > > > > > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct > > > > > 29 18:36:57 PDT 2009 > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > cpuid = 0; apic id = 00 > > > > > fault virtual address = 0x18 > > > > > > > > It looks like a NULL pointer dereference, possibly mbuf related > > > > one. > > > > > > > > > fault code = supervisor write data, page not present > > > > > instruction pointer = 0x8:0xffffffff80d476ee > > > > > stack pointer = 0x10:0xffffff8000078ae0 > > > > > frame pointer = 0x10:0xffffff8000078b40 > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > current process = 18 (swi5: +) > > > > > > By chance, did you stop the re0 interface with ifconfig when you > > > > noticed the file transfer got stuck? > > > > > > It is possible. I had it happen twice. The first time I definitely > > > tried to "down" re. I cannot recall what I did the second time. The > > > crash dump is from the second time. > > > > Ok, then would you try attached patch? > > I have been running with the patch for a couple of days. Although I can still > reproduce the lock-up of the network stack, I have not been able to reproduce > the panic. The patch does what it is supposed to do. > Thanks a lot for testing! Patch committed to HEAD(r198814) > I will continue to try to come up with a better test case for the file > transfer problem. However, I no longer suspect "re" as a cause. > > Thank you very much for your help. > > Cheers, > > -- Norbert Papke. > npapke@acm.org From daichi at ongs.co.jp Tue Nov 3 06:23:27 2009 From: daichi at ongs.co.jp (Daichi GOTO) Date: Tue Nov 3 06:23:35 2009 Subject: 8.0-RC1 ZFS loader extremely slow In-Reply-To: <2e027be00911020153j6b206e01td2b22a194a116565@mail.gmail.com> References: <2e027be00911020153j6b206e01td2b22a194a116565@mail.gmail.com> Message-ID: <20091103150602.bed6ba8d.daichi@ongs.co.jp> On Mon, 2 Nov 2009 09:53:30 +0000 Tom Evans wrote: > Hi all > > I just installed 8.0-RC1 amd64 on a 6 gpt disk ZFS raidz1 (following the > guide on the wiki), but > have problems on reboot with the newly installed ZFS aware loader. The > loader runs correctly, > but incredibly slowly. It takes about 2 hours to get to the point where it > enumerates the BIOS > disks, although when it gets to that point, it does not take a long time to > enumerate each > disk. It takes about 2 minutes for each character change of the spinner! > > Fully completing the loader takes somewhere between 2 and 8 hours (I got > bored watching it), > and works correctly. The loader from the memstick image works normally. > > Daichi GOTO experienced something similar back in January [1], but there > didn't seem to be > any resolution to that problem. Disabling AHCI has no effect. Interestingly, > we both have P45 > based motherboards. Unfortunately, slow loader process of FreeBSD is still been in my box. Even on latest 9-current/amd64, situation is the same... As workaround, I have splited my disk to small UFS partitions including minimum distrition install by make installworld/installkernel and ZFS partition. Removed all loading kernel module config from /etc/loaderc.conf to get up boot speed. Yes, it's just a workaround not fixed. > I will try installing 8.0-RC2 tonight, and try to save verbose boot logs, > dmidecode etc. If there > is any other information I should be looking at, please let me know. > > Cheers > > Tom > > > > [1] > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-02/msg00108.html -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From gphoto6 at gmail.com Tue Nov 3 08:29:34 2009 From: gphoto6 at gmail.com (Tim Chen) Date: Tue Nov 3 08:29:41 2009 Subject: Increasing number of "requests for jumbo clusters denied" in netstat -m Message-ID: <1f51039c0911030029k7e25e3bcxea941ff542311d59@mail.gmail.com> My machine is an IBM HS21 blade server and the NIC is bce. bce1: mem 0xd8000000-0xd9ffffff irq 19 at device 0.0 on pci6 miibus1: on bce1 bce1: Ethernet address: 00:1a:64:34:f2:fa bce1: [ITHREAD] bce1: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (0x03040405) ; Flags( MSI ) That machine is serving as a mail and web server. Recently I found that the number of "requests for jumbo clusters denied" in netstat -m increases all the time. 1031/3469/4500 mbufs in use (current/cache/total) 510/3326/3836/32768 mbuf clusters in use (current/cache/total/max) 510/2278 mbuf+clusters out of packet secondary zone in use (current/cache) 1/1453/1454/8704 4k (page size) jumbo clusters in use (current/cache/total/max) 510/1086/1596/4352 9k jumbo clusters in use (current/cache/total/max) 0/0/0/2176 16k jumbo clusters in use (current/cache/total/max) 5871K/23105K/28977K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/4337166/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ifconfig shows: bce1: flags=8843 metric 0 mtu 9000 options=1bb ether 00:1a:64:34:f2:fa inet 192.168.152.152 netmask 0xffffff00 broadcast 192.168.152.255 media: Ethernet autoselect (1000baseSX ) status: active And in rc.conf: ifconfig_bce1="inet 192.168.152.152 netmask 255.255.255.0 mtu 9000" Is the problem of increasing "requests for jumbo clusters denied" resulted from my "mtu 9000" jumbo frame setting? Will it be the problem of "bce" nic's driver or hardware? Most of all, how will my system be efftected by that ""requests for jumbo clusters denied" problem? Will it degrade the performance or it is harmless? Thanks for your help. BR, Tim Chen From egrosbein at rdtc.ru Tue Nov 3 11:02:20 2009 From: egrosbein at rdtc.ru (Eugene Grosbein) Date: Tue Nov 3 11:02:27 2009 Subject: Increasing number of "requests for jumbo clusters denied" in netstat -m In-Reply-To: <1f51039c0911030029k7e25e3bcxea941ff542311d59@mail.gmail.com> References: <1f51039c0911030029k7e25e3bcxea941ff542311d59@mail.gmail.com> Message-ID: <4AF007E7.8080805@rdtc.ru> Tim Chen wrote: > That machine is serving as a mail and web server. Recently I found that the > number of "requests for jumbo clusters denied" in netstat -m increases all > the time. > > 1031/3469/4500 mbufs in use (current/cache/total) > 510/3326/3836/32768 mbuf clusters in use (current/cache/total/max) > 510/2278 mbuf+clusters out of packet secondary zone in use (current/cache) > 1/1453/1454/8704 4k (page size) jumbo clusters in use > (current/cache/total/max) > 510/1086/1596/4352 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/2176 16k jumbo clusters in use (current/cache/total/max) > 5871K/23105K/28977K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/4337166/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines Look at "sysctl kern.ipc | fgrep nmb" Just increase limit (if you have enough memory :-) From oleg at FreeBSD.org Tue Nov 3 11:53:27 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Tue Nov 3 11:53:34 2009 Subject: interrupt threads CPU usage in FreeBSD 8.0 In-Reply-To: <20091021101243.GE3199@rambler-co.ru> References: <20091021101243.GE3199@rambler-co.ru> Message-ID: <20091103113943.GB47649@lath.rinet.ru> Yes, something is wrong (8.0-RC2): last pid: 7327; load averages: 0.31, 0.53, 0.55 up 0+03:51:35 14:36:22 81 processes: 5 running, 60 sleeping, 16 waiting CPU 0: 0.0% user, 0.0% nice, 0.0% system, 0.4% interrupt, 99.6% idle CPU 1: 0.0% user, 0.0% nice, 26.7% system, 0.0% interrupt, 73.3% idle CPU 2: 0.0% user, 0.0% nice, 25.6% system, 0.0% interrupt, 74.4% idle CPU 3: 0.0% user, 0.0% nice, 3.8% system, 0.0% interrupt, 96.2% idle Mem: 22M Active, 11M Inact, 157M Wired, 64K Cache, 23M Buf, 3754M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 64K CPU0 0 226:34 99.07% {idle: cpu0} 10 root 171 ki31 0K 64K RUN 3 221:56 95.56% {idle: cpu3} 10 root 171 ki31 0K 64K CPU1 1 179:58 73.10% {idle: cpu1} 10 root 171 ki31 0K 64K CPU2 2 175:32 68.07% {idle: cpu2} 0 root -68 0 0K 128K - 2 55:20 1.76% {em1 taskq} 11 root -32 - 0K 256K WAIT 0 2:10 0.29% {swi4: clock} 0 root -68 0 0K 128K - 1 50:42 0.00% {em0 taskq} em0 & em1 taskqueues should have wcpu ~25% -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From david at catwhisker.org Tue Nov 3 14:22:28 2009 From: david at catwhisker.org (David Wolfskill) Date: Tue Nov 3 14:36:39 2009 Subject: misc/compat6x port no longer sufficient for DRI under head? In-Reply-To: <20090917134924.GZ1212@albert.catwhisker.org> References: <20090917134924.GZ1212@albert.catwhisker.org> Message-ID: <20091103142227.GA1354@albert.catwhisker.org> On Thu, Sep 17, 2009 at 06:49:24AM -0700, David Wolfskill wrote: > [about X.org built under stable/6 no longer working under stable/7 or > head unless DRI was disabled, even with the compat6x port installed.] Last Sunday, I forgot to disable DRI when I rebuilt stable/7 -- and much to my pleasant surprise, X.org still worked. It has continued to work yesterday and today -- I just built: g1-99(7.2-S)[1] uname -a FreeBSD g1-99.catwhisker.org 7.2-STABLE FreeBSD 7.2-STABLE #965 r198786: Mon Nov 2 06:47:05 PST 2009 root@g1-99.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY i386 g1-99(7.2-S)[2] and am running X.org (built under stable/6) with DRI enabled. Last Sunday, I did veify, though, that attempting the same thing with head still fails -- though disabling DRI (in xorg.conf) circumvents the problem. Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091103/8ed54cd7/attachment.pgp From olli at lurza.secnetix.de Tue Nov 3 15:57:40 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Nov 3 15:58:01 2009 Subject: problems with gmirror on ggate over slow link In-Reply-To: Message-ID: <200911031557.nA3FvKm5061241@lurza.secnetix.de> Pete French wrote: > [...] > > Just a wild guess, have you tried to set kern.geom.mirror.timeout to a > > higher value? > > Yes, I tried values all the way up to 600, no effect at all - plus the > failure comes way before that timeout value (which is in seconds I assume). Have you done any sockets tuning? In an older posting the following values were recommended: /etc/sysctl.conf: net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 kern.ipc.maxsockbuf=2049152 /boot/loader.conf: kern.ipc.nmbclusters="32768" Command line options to ggate[cd]: ggate[dc]_buf_size="1310720" ggatec_timeout="5" ggatec_queue_size="2048" Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From petefrench at ticketswitch.com Tue Nov 3 16:23:33 2009 From: petefrench at ticketswitch.com (Pete French) Date: Tue Nov 3 16:23:40 2009 Subject: problems with gmirror on ggate over slow link In-Reply-To: <200911031557.nA3FvKm5061241@lurza.secnetix.de> Message-ID: > Have you done any sockets tuning? > In an older posting the following values were recommended: Yes, I need that to get the speed out of it for normal use to a disc on a machine on the same ether - but even so, surely it should block on a slow disc, not just abandon the mirroring ? -pete. From attilio at freebsd.org Tue Nov 3 16:36:57 2009 From: attilio at freebsd.org (Attilio Rao) Date: Tue Nov 3 16:37:30 2009 Subject: interrupt threads CPU usage in FreeBSD 8.0 In-Reply-To: <20091021101243.GE3199@rambler-co.ru> References: <20091021101243.GE3199@rambler-co.ru> Message-ID: <3bbf2fe10911030836r173b4b3boe606e2222fbdfff6@mail.gmail.com> 2009/10/21 Igor Sysoev : > Hi, > > for some reason in 8.0 top always shows 0% CPU usage for intr kernel > process and active interrupt thread, "irq19 bge0" in my case. > > 8-0 RC1 top -PS: > > CPU 0: 27.8% user, 0.0% nice, 7.1% system, 0.0% interrupt, 65.0% idle > CPU 1: 3.0% user, 0.0% nice, 2.3% system, 7.1% interrupt, 87.6% idle > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 2 171 ki31 0K 32K RUN 0 140.7H 152.54% idle > 61371 nobody 1 69 -10 384M 289M kqread 0 105:56 17.77% nginx > 61372 nobody 1 67 -10 384M 293M CPU0 0 106:15 16.99% nginx > 12 root 15 -60 - 0K 240K WAIT 0 54:50 0.00% intr > > 8.0 RC1 top -PSH: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 171 ki31 0K 32K RUN 1 71.5H 81.05% {idle: cpu1} > 11 root 171 ki31 0K 32K CPU0 0 69.3H 69.19% {idle: cpu0} > 61372 nobody 68 -10 384M 294M kqread 0 107:06 18.99% nginx > 61371 nobody 68 -10 384M 291M kqread 0 106:45 16.99% nginx > 12 root -68 - 0K 240K WAIT 1 50:48 0.00% {irq19: bge0} > 17 root 44 - 0K 16K syncer 1 5:23 0.00% syncer > 12 root -32 - 0K 240K WAIT 1 3:06 0.00% {swi4: clock} > > 7.2-STABLE top -PS: > > CPU 0: 9.0% user, 0.0% nice, 7.9% system, 9.0% interrupt, 74.1% idle > CPU 1: 23.3% user, 0.0% nice, 8.3% system, 0.0% interrupt, 68.4% idle > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 1 171 ki31 0K 16K RUN 0 275.0H 83.59% idle: cpu0 > 11 root 1 171 ki31 0K 16K RUN 1 264.2H 76.27% idle: cpu1 > 16109 nobody 1 68 -10 376M 307M CPU0 1 28:05 21.97% nginx > 16110 nobody 1 4 -10 376M 316M RUN 0 28:05 20.17% nginx > 26 root 1 -68 - 0K 16K WAIT 0 902:39 6.69% irq19: bge0 How old is your 7.2-STABLE? Attilio -- Peace can only be achieved by understanding - A. Einstein From is at rambler-co.ru Tue Nov 3 16:48:01 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Tue Nov 3 16:48:09 2009 Subject: interrupt threads CPU usage in FreeBSD 8.0 In-Reply-To: <3bbf2fe10911030836r173b4b3boe606e2222fbdfff6@mail.gmail.com> References: <20091021101243.GE3199@rambler-co.ru> <3bbf2fe10911030836r173b4b3boe606e2222fbdfff6@mail.gmail.com> Message-ID: <20091103164759.GI6305@rambler-co.ru> On Tue, Nov 03, 2009 at 05:36:55PM +0100, Attilio Rao wrote: > 2009/10/21 Igor Sysoev : > > Hi, > > > > for some reason in 8.0 top always shows 0% CPU usage for intr kernel > > process and active interrupt thread, "irq19 bge0" in my case. > > > > 8-0 RC1 top -PS: > > > > CPU 0: 27.8% user, 0.0% nice, 7.1% system, 0.0% interrupt, 65.0% idle > > CPU 1: 3.0% user, 0.0% nice, 2.3% system, 7.1% interrupt, 87.6% idle > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 11 root 2 171 ki31 0K 32K RUN 0 140.7H 152.54% idle > > 61371 nobody 1 69 -10 384M 289M kqread 0 105:56 17.77% nginx > > 61372 nobody 1 67 -10 384M 293M CPU0 0 106:15 16.99% nginx > > 12 root 15 -60 - 0K 240K WAIT 0 54:50 0.00% intr > > > > 8.0 RC1 top -PSH: > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 11 root 171 ki31 0K 32K RUN 1 71.5H 81.05% {idle: cpu1} > > 11 root 171 ki31 0K 32K CPU0 0 69.3H 69.19% {idle: cpu0} > > 61372 nobody 68 -10 384M 294M kqread 0 107:06 18.99% nginx > > 61371 nobody 68 -10 384M 291M kqread 0 106:45 16.99% nginx > > 12 root -68 - 0K 240K WAIT 1 50:48 0.00% {irq19: bge0} > > 17 root 44 - 0K 16K syncer 1 5:23 0.00% syncer > > 12 root -32 - 0K 240K WAIT 1 3:06 0.00% {swi4: clock} > > > > 7.2-STABLE top -PS: > > > > CPU 0: 9.0% user, 0.0% nice, 7.9% system, 9.0% interrupt, 74.1% idle > > CPU 1: 23.3% user, 0.0% nice, 8.3% system, 0.0% interrupt, 68.4% idle > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 12 root 1 171 ki31 0K 16K RUN 0 275.0H 83.59% idle: cpu0 > > 11 root 1 171 ki31 0K 16K RUN 1 264.2H 76.27% idle: cpu1 > > 16109 nobody 1 68 -10 376M 307M CPU0 1 28:05 21.97% nginx > > 16110 nobody 1 4 -10 376M 316M RUN 0 28:05 20.17% nginx > > 26 root 1 -68 - 0K 16K WAIT 0 902:39 6.69% irq19: bge0 > > How old is your 7.2-STABLE? I saw this on 7.0-7.2. One of 7.2-S is, for example, from 2009.10.04.23.59.59. I believe I saw the same CPU usage on FreeBSD-6 too. -- Igor Sysoev http://sysoev.ru/en/ From rui.pfcosta at gmail.com Tue Nov 3 16:59:52 2009 From: rui.pfcosta at gmail.com (Rui Costa) Date: Tue Nov 3 17:00:02 2009 Subject: Installation boot sequence freeze Message-ID: When installing freebsd (7.2, 8.0 betas, rc1, rc2 - AMD64) on a Clevo M540SR laptop (chipset VIA VN896), after menu option selection, the boot process freezes at "Trying to mount root from ufs:/dev/md0". On verbose booting it freezes giving some mode information: md0: Preloaded image 4194304 bytes at 0xffffffff80c4be40 ATA PseudoRAID loaded flowtable cleaner started warning: no time-of-day clock registered, system time will not be set accurately Trying to mount root from ufs:/dev/md0 Start_init: trying /sbin/init Start_init: trying /sbin/oinit Start_init: trying /sbin/init.bak Start_init: trying /rescue/init Start_init: trying /stand/sysinstall I've tried already several boot hints (any of them with success) such as: apic.0.disabled = 1 sio.0.disasabled = 1 sio.1.disabled = 1 fdc.disabled = 1 kbdmux.0.disabled = 1 A possible solution I found over the internet would be to disable USB 2.0 support on bios, but bios options are very limited and won't allow me to do that. FreeBSD 6.4 install and later upgrade to 7.0 went flawlessly, but upgrade to 7.2 brings up the freezes again on boot. From kvs at binarysolutions.dk Tue Nov 3 17:15:25 2009 From: kvs at binarysolutions.dk (Kenneth Schmidt) Date: Tue Nov 3 17:15:36 2009 Subject: 8.0-RC2's /boot/loader doesn't like booting from ZFS? Message-ID: <90FB6778-7853-420E-8931-9EE78E95E8F1@binarysolutions.dk> Hello. Two separate machines fail when starting loader(8) after upgrading from 8.0-RC1 to -RC2. Both have been installed by following http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot - one is a VMware machine with just one disk, the other a Sun Fire X2200 server with 2 disks in a ZFS mirror. They both booted fine with -RC1, but with -RC2 the last messages are: Can't work out which disk we are booting from. Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0: ficl-s not found Assertion failed: (FALSE), function ficlCompileSoftCore, file softcore.c, line 428. Reverting to the -RC1 /boot/loader fixes. -- Best Regards Kenneth Vestergaard Schmidt From tom at tomjudge.com Tue Nov 3 19:23:44 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Nov 3 19:23:51 2009 Subject: Increasing number of "requests for jumbo clusters denied" in netstat -m In-Reply-To: <1f51039c0911030029k7e25e3bcxea941ff542311d59@mail.gmail.com> References: <1f51039c0911030029k7e25e3bcxea941ff542311d59@mail.gmail.com> Message-ID: <4AF082FF.2070601@tomjudge.com> Tim Chen wrote: > My machine is an IBM HS21 blade server and the NIC is bce. > > bce1: mem > 0xd8000000-0xd9ffffff irq 19 at device 0.0 on pci6 > miibus1: on bce1 > bce1: Ethernet address: 00:1a:64:34:f2:fa > bce1: [ITHREAD] > bce1: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (0x03040405) ; Flags( MSI ) > > That machine is serving as a mail and web server. Recently I found that the > number of "requests for jumbo clusters denied" in netstat -m increases all > the time. > > 1031/3469/4500 mbufs in use (current/cache/total) > 510/3326/3836/32768 mbuf clusters in use (current/cache/total/max) > 510/2278 mbuf+clusters out of packet secondary zone in use (current/cache) > 1/1453/1454/8704 4k (page size) jumbo clusters in use > (current/cache/total/max) > 510/1086/1596/4352 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/2176 16k jumbo clusters in use (current/cache/total/max) > 5871K/23105K/28977K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/4337166/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > ifconfig shows: > bce1: flags=8843 metric 0 mtu 9000 > > options=1bb TSO4> > ether 00:1a:64:34:f2:fa > inet 192.168.152.152 netmask 0xffffff00 broadcast 192.168.152.255 > media: Ethernet autoselect (1000baseSX ) > status: active > > And in rc.conf: > ifconfig_bce1="inet 192.168.152.152 netmask 255.255.255.0 mtu 9000" > > Is the problem of increasing "requests for jumbo clusters denied" resulted > from my "mtu 9000" jumbo frame setting? > Will it be the problem of "bce" nic's driver or hardware? > Most of all, how will my system be efftected by that ""requests for jumbo > clusters denied" problem? Will it degrade > the performance or it is harmless? > > Second thread on this bug today :) There is a bug in bce(4) that causes memory fragmentation, which results in denied mbuf requests as you are seeing. You can correct this issue by applying the patch created by this command: svn diff -r 198319:198320 http://svn.freebsd.org/base/head Once you have applied the patch you need to add: options BCE_JUMBO_HDRSPLIT To you kernel config and recompile and install the new kernel. Hope this works for you. Tom From delphij at delphij.net Tue Nov 3 23:31:39 2009 From: delphij at delphij.net (Xin LI) Date: Tue Nov 3 23:31:46 2009 Subject: make release stop at cdrtools In-Reply-To: <20091025081422.20341pp8zbvuupgu@webmail.tint.or.th> References: <20091025081422.20341pp8zbvuupgu@webmail.tint.or.th> Message-ID: <4AF0BD49.6000507@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ????? ??????? wrote: [...] > the build process goes well but then fetching for cdrtools.tbz begin and > stop. > in my machine i have installed cdrtools and there is also mkisofs file > so i wonder why the script /usr/src/release/i386/mkisofsimages.sh still > fetching for cdrtools. It's referring the chroot environment. You can actually do 'make iso.1' after the build process which will use cdrtool outside the chroot'ed environment. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrwvUkACgkQi+vbBBjt66BANQCfQ9CzWH6/gM1kP6ZoszVrBgV7 5sMAn1MQYDOUJ4BW5o29IgD9oIUOj33H =QYIf -----END PGP SIGNATURE----- From =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= Wed Nov 4 01:40:56 2009 From: =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= (=?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?=) Date: Wed Nov 4 01:41:03 2009 Subject: make release stop at cdrtools In-Reply-To: <4AF0BD49.6000507@delphij.net> References: <20091025081422.20341pp8zbvuupgu@webmail.tint.or.th> <4AF0BD49.6000507@delphij.net> Message-ID: <20091104081310.148021vxp9j2zuw6@webmail.tint.or.th> Quoting Xin LI : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ????? ??????? wrote: > [...] >> the build process goes well but then fetching for cdrtools.tbz begin and >> stop. >> in my machine i have installed cdrtools and there is also mkisofs file >> so i wonder why the script /usr/src/release/i386/mkisofsimages.sh still >> fetching for cdrtools. > > It's referring the chroot environment. You can actually do 'make iso.1' > after the build process which will use cdrtool outside the chroot'ed > environment. > oh many thanks indeed. this clarifies me a lot of things. i will try now. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.13 (FreeBSD) > > iEYEARECAAYFAkrwvUkACgkQi+vbBBjt66BANQCfQ9CzWH6/gM1kP6ZoszVrBgV7 > 5sMAn1MQYDOUJ4BW5o29IgD9oIUOj33H > =QYIf > -----END PGP SIGNATURE----- > with best regards, -- psr ????? ????????? ???? ?????????? http://makham.blogspot.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From ota at j.email.ne.jp Wed Nov 4 01:41:22 2009 From: ota at j.email.ne.jp (Yoshihiro Ota) Date: Wed Nov 4 01:41:39 2009 Subject: problems with gmirror on ggate over slow link In-Reply-To: References: <200911031557.nA3FvKm5061241@lurza.secnetix.de> Message-ID: <20091103202238.7a756e6e.ota@j.email.ne.jp> I think you hit the same bug as I did a while ago. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/132798 You can get a patch at PR and give a try. Make sure you update both server and client; otherwise, it will cause a panic or so. Hiro On Tue, 03 Nov 2009 16:23:24 +0000 Pete French wrote: > > Have you done any sockets tuning? > > In an older posting the following values were recommended: > > Yes, I need that to get the speed out of it for normal use > to a disc on a machine on the same ether - but even so, surely > it should block on a slow disc, not just abandon the mirroring ? > > -pete. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From david at catwhisker.org Wed Nov 4 05:45:36 2009 From: david at catwhisker.org (David Wolfskill) Date: Wed Nov 4 05:45:44 2009 Subject: stable/7 i386 seems more "stable" at r197725 than r198747 does Message-ID: <20091104054534.GA3614@albert.catwhisker.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091104/12f5b236/attachment.pgp From gerrit at pmp.uni-hannover.de Wed Nov 4 08:29:04 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Wed Nov 4 08:29:11 2009 Subject: zfs panic mounting fs after crash with RC2 Message-ID: <20091104092900.29b4518a.gerrit@pmp.uni-hannover.de> Hi, Yesterday I had the opportunity to play around with my yet-to-become new fileserver a bit more. Originally I had installed 7.2-R, which I upgraded to 8-0-RC2 yesterday. After that I upgraded my zpool consisting of 4 disks in raidz1 constallation to v13. Some time later I tried to use powerd which was obviously a bad idea: it crashed the machine immediately. I will give a separate report on that later as it is probably related to the hardware, which is a bit exotic (VIA VB8001 board with 64bit Via Nano processor). However, the worst thing for me is, that after rebooting from that crash, one of my zfs fs cannot be mounted anymore. As soon as I try to mount it I get a kernel panic. I can still access the properties (I made use of "canmount=noauto" for the first time :-), but I cannot do a snapshot of the fs (funny enough, zfs complains that the fs is busy, while in reality it is not even mounted - so how could it be busy?). I took a picture of the kernel panic and put it here (don't know if there is any useful information in it): The pool as such seems to be fine, all other fs in it can be mounted and used, only trying to mount tank/sys/var triggers this panic. Are there any suggestions what I could do to get my fs back? Please let me know if (and how) I can provide more debugging information. cu Gerrit From dudu at dudu.ro Wed Nov 4 11:42:12 2009 From: dudu at dudu.ro (Vlad Galu) Date: Wed Nov 4 11:42:20 2009 Subject: interrupt threads CPU usage in FreeBSD 8.0 In-Reply-To: <20091021101243.GE3199@rambler-co.ru> References: <20091021101243.GE3199@rambler-co.ru> Message-ID: 2009/10/21 Igor Sysoev : [...] /metoo, 8.0-RC2 From mike.barnardq at gmail.com Wed Nov 4 12:58:08 2009 From: mike.barnardq at gmail.com (Mike Barnard) Date: Wed Nov 4 12:58:15 2009 Subject: Broadcom BCM5715 not coming up Message-ID: <7dc029620911040434v7145b8afue945f2e3930dfb75@mail.gmail.com> Hi, I am experiencing a weird problem on an HP ProLiant BL480c G1 with a Broadcom Dual Gigabit network card. For some reason, it wont come up. I have tried it with different media speeds, options but nothing. I upgraded my sources, recompiled and installed from FreeBSD 7.1-PRERELEASE to 7.2-STABLE but I get the same error. pciconf -lv shows this: pcib5@pci0:9:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xb5 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Broadcom dual gigabit, pci bridge (BCM5715)' class = bridge subclass = PCI-PCI bge0@pci0:10:4:0: class=0x020000 card=0x703c103c chip=0x167914e4 rev=0xa3 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme 5715S Gigabit Ethernet' class = network subclass = ethernet bge1@pci0:10:4:1: class=0x020000 card=0x703c103c chip=0x167914e4 rev=0xa3 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme 5715S Gigabit Ethernet' class = network subclass = ethernet dmesg, clipped, shows this: pcib5: at device 0.0 on pci9 pci10: on pcib5 bge0: mem 0xfdef0000-0xfdefffff,0xfdee0000-0xfdeeffff irq 17 at device 4.0 on pci10 bge0: Ethernet address: 00:1a:4b:cf:3e:3f bge0: [ITHREAD] bge1: mem 0xfded0000-0xfdedffff,0xfdec0000-0xfdecffff irq 18 at device 4.1 on pci10 bge1: Ethernet address: 00:1a:4b:cf:3e:40 bge1: [ITHREAD] ... ... bce0: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 miibus0: on bce0 brgphy0: PHY 2 on miibus0 brgphy0: 1000baseSX-FDX, auto bce0: Ethernet address: 00:1b:78:02:7c:56 bce0: [ITHREAD] bce0: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (0x01090605); Flags( MSI ) pcib14: at device 28.1 on pci0 pci4: on pcib14 pcib15: at device 0.0 on pci4 pci5: on pcib15 bce1: mem 0xfa000000-0xfbffffff irq 17 at device 0.0 on pci5 miibus1: on bce1 brgphy1: PHY 2 on miibus1 brgphy1: 1000baseSX-FDX, auto bce1: Ethernet address: 00:1b:78:02:7c:4e bce1: [ITHREAD] bce1: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (0x01090605); Flags( MSI ) The bge interface is seen as NetXtreme 5715S Gigabit Ethernet, while the bce interface is seen as NetXtreme II BCM5708S Gigabit Ethernet Anyone seen this before... Im lost on this one :-/ any direction is welcome. -- Mike Of course, you might discount this possibility, but remember that one in a million chances happen 99% of the time. ------------------------------------------------------------ From jhb at freebsd.org Wed Nov 4 13:18:34 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 4 13:18:45 2009 Subject: 8.0-RC2's /boot/loader doesn't like booting from ZFS? In-Reply-To: <90FB6778-7853-420E-8931-9EE78E95E8F1@binarysolutions.dk> References: <90FB6778-7853-420E-8931-9EE78E95E8F1@binarysolutions.dk> Message-ID: <200911040814.37997.jhb@freebsd.org> On Tuesday 03 November 2009 11:54:12 am Kenneth Schmidt wrote: > Hello. > > Two separate machines fail when starting loader(8) after upgrading > from 8.0-RC1 to -RC2. Both have been installed by following http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot > - one is a VMware machine with just one disk, the other a Sun Fire > X2200 server with 2 disks in a ZFS mirror. > > They both booted fine with -RC1, but with -RC2 the last messages are: > > Can't work out which disk we are booting from. > Guessed BIOS device 0xffffffff not found by probes, defaulting to > disk0: > ficl-s not found > Assertion failed: (FALSE), function ficlCompileSoftCore, file > softcore.c, line 428. > > Reverting to the -RC1 /boot/loader fixes. Usually the 'Guessed BIOS device' stuff is caused by the loader re-executing itself, perhaps due to a stack overflow. -- John Baldwin From rhurlin at gwdg.de Wed Nov 4 14:13:03 2009 From: rhurlin at gwdg.de (Rainer Hurling) Date: Wed Nov 4 14:13:12 2009 Subject: Connection errors with driver isp(fw) on QLogic 2562 Message-ID: <4AF18269.2040409@gwdg.de> Our system is a dual quad core xeon system with FreeBSD 8.0-RC2 (amd64). A dual port QLogic 2562 is connected to a QLogic SANBox 5800V to which two raids are attached. The HBA reports firmware version 4.03.01, BIOS version 2.02. Devices isp and ispfw are configured in kernel config file. The configuration with 4GBit GBics runs just fine. When we install 8GBit GBics, which is what we actually would like to use, the problems start: As soon as we have heavy write access to the raids we get connection errors. Our hardware vendor came up with some configuration options. "Don't use auto speed on connections" and the like. All without success. See the attached extracs from /var/log/messages. In the file there are three parts with different configuration settings on the hardware. The settings used are at the top of the messages. The last part is with 4GBit without errors. Is it helpful to bring the firmware of the HBA up to date with firmware 4.06.02? Or does it use the driver firmware from /usr/src/sys/dev/ispfw/asm_2500.h? If so, are you planning on updating asm_2500.h from 4.06.00 to 4.06.02? Any other ideas? Thanks in advance, Rainer Hurling -------------- next part -------------- # # FC-Switch, Raid 1+2 set to 8GBit, Server set to auto speed , with 8Gbit GBic # Oct 9 15:32:22 Server syslogd: exiting on signal 15 Oct 9 15:36:31 Server syslogd: kernel boot file is /boot/kernel/kernel Oct 9 15:36:31 Server kernel: Copyright (c) 1992-2009 The FreeBSD Project. Oct 9 15:36:31 Server kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 9 15:36:31 Server kernel: The Regents of the University of California. All rights reserved. Oct 9 15:36:31 Server kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Oct 9 15:36:31 Server kernel: FreeBSD 8.0-RC1 #3: Fri Oct 9 15:27:23 CEST 2009 Oct 9 15:36:31 Server kernel: toor@Server:/usr/obj/usr/src/sys/KOMBJUDA Oct 9 15:36:31 Server kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Oct 9 15:36:31 Server kernel: CPU: Intel(R) Xeon(R) CPU E7440 @ 2.40GHz (2394.02-MHz K8-class CPU) Oct 9 15:36:31 Server kernel: Origin = "GenuineIntel" Id = 0x106d1 Stepping = 1 Oct 9 15:36:31 Server kernel: Features=0xbfebfbff Oct 9 15:36:31 Server kernel: Features2=0xce3bd Oct 9 15:36:31 Server kernel: AMD Features=0x20100800 Oct 9 15:36:31 Server kernel: AMD Features2=0x1 Oct 9 15:36:31 Server kernel: TSC: P-state invariant Oct 9 15:36:31 Server kernel: real memory = 103079215104 (98304 MB) Oct 9 15:36:31 Server kernel: avail memory = 99536936960 (94925 MB) Oct 9 15:36:31 Server kernel: ACPI APIC Table: <080808 APIC1448> Oct 9 15:36:31 Server kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs Oct 9 15:36:31 Server kernel: FreeBSD/SMP: 2 package(s) x 4 core(s) Oct 9 15:36:31 Server kernel: cpu0 (BSP): APIC ID: 0 Oct 9 15:36:31 Server kernel: cpu1 (AP): APIC ID: 1 Oct 9 15:36:31 Server kernel: cpu2 (AP): APIC ID: 2 Oct 9 15:36:31 Server kernel: cpu3 (AP): APIC ID: 3 Oct 9 15:36:31 Server kernel: cpu4 (AP): APIC ID: 8 Oct 9 15:36:31 Server kernel: cpu5 (AP): APIC ID: 9 Oct 9 15:36:31 Server kernel: cpu6 (AP): APIC ID: 10 Oct 9 15:36:31 Server kernel: cpu7 (AP): APIC ID: 11 Oct 9 15:36:31 Server kernel: ioapic0: Changing APIC ID to 12 Oct 9 15:36:31 Server kernel: ioapic1: Changing APIC ID to 13 Oct 9 15:36:31 Server kernel: ioapic0 irqs 0-23 on motherboard Oct 9 15:36:31 Server kernel: ioapic1 irqs 24-47 on motherboard Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: ispfw: registered firmware Oct 9 15:36:31 Server kernel: kbd1 at kbdmux0 Oct 9 15:36:31 Server kernel: acpi0: <080808 XSDT1448> on motherboard Oct 9 15:36:31 Server kernel: acpi0: [ITHREAD] Oct 9 15:36:31 Server kernel: acpi0: Power Button (fixed) Oct 9 15:36:31 Server kernel: acpi0: reservation of 0, a0000 (3) failed Oct 9 15:36:31 Server kernel: acpi0: reservation of 100000, bff00000 (3) failed Oct 9 15:36:31 Server kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Oct 9 15:36:31 Server kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Oct 9 15:36:31 Server kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Oct 9 15:36:31 Server kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Oct 9 15:36:31 Server kernel: pcib0: port 0xcf8-0xcff on acpi0 Oct 9 15:36:31 Server kernel: pci0: on pcib0 Oct 9 15:36:31 Server kernel: pcib1: irq 16 at device 1.0 on pci0 Oct 9 15:36:31 Server kernel: pci12: on pcib1 Oct 9 15:36:31 Server kernel: igb0: port 0xec00-0xec1f mem 0xfdee0000-0xfdefffff,0xfdec0000-0xfdedffff,0xfdebc000-0xfdebffff irq 16 at device 0.0 on pci12 Oct 9 15:36:31 Server kernel: igb0: Using MSIX interrupts with 3 vectors Oct 9 15:36:31 Server kernel: igb0: [ITHREAD] Oct 9 15:36:31 Server last message repeated 2 times Oct 9 15:36:31 Server kernel: igb0: Ethernet address: 00:30:48:d0:44:b6 Oct 9 15:36:31 Server kernel: igb1: port 0xe880-0xe89f mem 0xfde60000-0xfde7ffff,0xfde40000-0xfde5ffff,0xfdeb8000-0xfdebbfff irq 17 at device 0.1 on pci12 Oct 9 15:36:31 Server kernel: igb1: Using MSIX interrupts with 3 vectors Oct 9 15:36:31 Server kernel: igb1: [ITHREAD] Oct 9 15:36:31 Server last message repeated 2 times Oct 9 15:36:31 Server kernel: igb1: Ethernet address: 00:30:48:d0:44:b7 Oct 9 15:36:31 Server kernel: pcib2: irq 16 at device 2.0 on pci0 Oct 9 15:36:31 Server kernel: pci8: on pcib2 Oct 9 15:36:31 Server kernel: pcib3: irq 16 at device 0.0 on pci8 Oct 9 15:36:31 Server kernel: pci10: on pcib3 Oct 9 15:36:31 Server kernel: pcib4: at device 0.0 on pci10 Oct 9 15:36:31 Server kernel: pci11: on pcib4 Oct 9 15:36:31 Server kernel: mpt0: port 0xd800-0xd8ff mem 0xfdcfc000-0xfdcfffff,0xfdce0000-0xfdceffff irq 16 at device 0.0 on pci11 Oct 9 15:36:31 Server kernel: mpt0: [ITHREAD] Oct 9 15:36:31 Server kernel: mpt0: MPI Version=1.5.19.0 Oct 9 15:36:31 Server kernel: pcib5: at device 0.3 on pci8 Oct 9 15:36:31 Server kernel: pci9: on pcib5 Oct 9 15:36:31 Server kernel: pcib6: irq 16 at device 4.0 on pci0 Oct 9 15:36:31 Server kernel: pci7: on pcib6 Oct 9 15:36:31 Server kernel: pcib7: irq 16 at device 6.0 on pci0 Oct 9 15:36:31 Server kernel: pci3: on pcib7 Oct 9 15:36:31 Server kernel: pcib8: at device 0.0 on pci3 Oct 9 15:36:31 Server kernel: pci4: on pcib8 Oct 9 15:36:31 Server kernel: pcib9: at device 2.0 on pci4 Oct 9 15:36:31 Server kernel: pci6: on pcib9 Oct 9 15:36:31 Server kernel: em0: port 0xcc00-0xcc1f mem 0xfd7e0000-0xfd7fffff,0xfd7c0000-0xfd7dffff irq 19 at device 0.0 on pci6 Oct 9 15:36:31 Server kernel: em0: Using MSI interrupt Oct 9 15:36:31 Server kernel: em0: [FILTER] Oct 9 15:36:31 Server kernel: em0: Ethernet address: 00:15:17:aa:23:65 Oct 9 15:36:31 Server kernel: em1: port 0xc880-0xc89f mem 0xfd780000-0xfd79ffff,0xfd760000-0xfd77ffff irq 18 at device 0.1 on pci6 Oct 9 15:36:31 Server kernel: em1: Using MSI interrupt Oct 9 15:36:31 Server kernel: em1: [FILTER] Oct 9 15:36:31 Server kernel: em1: Ethernet address: 00:15:17:aa:23:64 Oct 9 15:36:31 Server kernel: pcib10: at device 4.0 on pci4 Oct 9 15:36:31 Server kernel: pci5: on pcib10 Oct 9 15:36:31 Server kernel: em2: port 0xbc00-0xbc1f mem 0xfd5e0000-0xfd5fffff,0xfd5c0000-0xfd5dffff irq 17 at device 0.0 on pci5 Oct 9 15:36:31 Server kernel: em2: Using MSI interrupt Oct 9 15:36:31 Server kernel: em2: [FILTER] Oct 9 15:36:31 Server kernel: em2: Ethernet address: 00:15:17:aa:23:67 Oct 9 15:36:31 Server kernel: em3: port 0xb880-0xb89f mem 0xfd580000-0xfd59ffff,0xfd560000-0xfd57ffff irq 16 at device 0.1 on pci5 Oct 9 15:36:31 Server kernel: em3: Using MSI interrupt Oct 9 15:36:31 Server kernel: em3: [FILTER] Oct 9 15:36:31 Server kernel: em3: Ethernet address: 00:15:17:aa:23:66 Oct 9 15:36:31 Server kernel: pci0: at device 8.0 (no driver attached) Oct 9 15:36:31 Server kernel: pcib11: irq 16 at device 28.0 on pci0 Oct 9 15:36:31 Server kernel: pci2: on pcib11 Oct 9 15:36:31 Server kernel: isp0: port 0xa800-0xa8ff mem 0xfd3fc000-0xfd3fffff irq 16 at device 0.0 on pci2 Oct 9 15:36:31 Server kernel: isp0: [ITHREAD] Oct 9 15:36:31 Server kernel: isp1: port 0xa400-0xa4ff mem 0xfd3f8000-0xfd3fbfff irq 17 at device 0.1 on pci2 Oct 9 15:36:31 Server kernel: isp1: [ITHREAD] Oct 9 15:36:31 Server kernel: pcib12: at device 30.0 on pci0 Oct 9 15:36:31 Server kernel: pci1: on pcib12 Oct 9 15:36:31 Server kernel: vgapci0: port 0x9000-0x90ff mem 0xd0000000-0xd7ffffff,0xfd1f0000-0xfd1fffff at device 1.0 on pci1 Oct 9 15:36:31 Server kernel: isab0: at device 31.0 on pci0 Oct 9 15:36:31 Server kernel: isa0: on isab0 Oct 9 15:36:31 Server kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 Oct 9 15:36:31 Server kernel: ata0: on atapci0 Oct 9 15:36:31 Server kernel: ata0: [ITHREAD] Oct 9 15:36:31 Server kernel: pci0: at device 31.3 (no driver attached) Oct 9 15:36:31 Server kernel: acpi_button0: on acpi0 Oct 9 15:36:31 Server kernel: atrtc0: port 0x70-0x71 irq 8 on acpi0 Oct 9 15:36:31 Server kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 Oct 9 15:36:31 Server kernel: uart0: [FILTER] Oct 9 15:36:31 Server kernel: uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 Oct 9 15:36:31 Server kernel: uart1: [FILTER] Oct 9 15:36:31 Server kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Oct 9 15:36:31 Server kernel: atkbd0: irq 1 on atkbdc0 Oct 9 15:36:31 Server kernel: kbd0 at atkbd0 Oct 9 15:36:31 Server kernel: atkbd0: [GIANT-LOCKED] Oct 9 15:36:31 Server kernel: atkbd0: [ITHREAD] Oct 9 15:36:31 Server kernel: orm0: at iomem 0xc0000-0xcafff,0xd3800-0xd47ff,0xd4800-0xd57ff on isa0 Oct 9 15:36:31 Server kernel: sc0: on isa0 Oct 9 15:36:31 Server kernel: sc0: VGA <16 virtual consoles, flags=0x300> Oct 9 15:36:31 Server kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Oct 9 15:36:31 Server kernel: ZFS filesystem version 13 Oct 9 15:36:31 Server kernel: ZFS storage pool version 13 Oct 9 15:36:31 Server kernel: Timecounters tick every 1.000 msec Oct 9 15:36:31 Server kernel: acd0: DVDROM at ata0-slave UDMA33 Oct 9 15:36:31 Server kernel: da0 at mpt0 bus 0 target 1 lun 0 Oct 9 15:36:31 Server kernel: da0: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da0: 300.000MB/s transfers Oct 9 15:36:31 Server kernel: da0: Command Queueing enabled Oct 9 15:36:31 Server kernel: da0: 122104MB (250069680 512 byte sectors: 255H 63S/T 15566C) Oct 9 15:36:31 Server kernel: da1 at mpt0 bus 0 target 2 lun 0 Oct 9 15:36:31 Server kernel: da1: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da1: 300.000MB/s transfers Oct 9 15:36:31 Server kernel: da1: Command Queueing enabled Oct 9 15:36:31 Server kernel: da1: 122104MB (250069680 512 byte sectors: 255H 63S/T 15566C) Oct 9 15:36:31 Server kernel: da2 at mpt0 bus 0 target 3 lun 0 Oct 9 15:36:31 Server kernel: da2: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da2: 300.000MB/s transfers Oct 9 15:36:31 Server kernel: da2: Command Queueing enabled Oct 9 15:36:31 Server kernel: da2: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:36:31 Server kernel: da3 at mpt0 bus 0 target 5 lun 0 Oct 9 15:36:31 Server kernel: da3: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da3: 300.000MB/s transfers Oct 9 15:36:31 Server kernel: da3: Command Queueing enabled Oct 9 15:36:31 Server kernel: da3: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:36:31 Server kernel: da4 at mpt0 bus 0 target 6 lun 0 Oct 9 15:36:31 Server kernel: da4: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da4: 300.000MB/s transfers Oct 9 15:36:31 Server kernel: da4: Command Queueing enabled Oct 9 15:36:31 Server kernel: da4: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:36:31 Server kernel: da5 at mpt0 bus 0 target 7 lun 0 Oct 9 15:36:31 Server kernel: da5: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da5: 300.000MB/s transfers Oct 9 15:36:31 Server kernel: da5: Command Queueing enabled Oct 9 15:36:31 Server kernel: da5: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:36:31 Server kernel: da7 at isp1 bus 0 target 0 lun 0 Oct 9 15:36:31 Server kernel: da7: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da7: 800.000MB/s transfers Oct 9 15:36:31 Server kernel: da7: Command Queueing enabled Oct 9 15:36:31 Server kernel: da7: 13350582MB (27341991936 512 byte sectors: 255H 63S/T 1701960C) Oct 9 15:36:31 Server kernel: da6 at isp0 bus 0 target 0 lun 0 Oct 9 15:36:31 Server kernel: da6: Fixed Direct Access SCSI-5 device Oct 9 15:36:31 Server kernel: da6: 800.000MB/s transfers Oct 9 15:36:31 Server kernel: da6: Command Queueing enabled Oct 9 15:36:31 Server kernel: da6: 13350582MB (27341991936 512 byte sectors: 255H 63S/T 1701960C) Oct 9 15:36:31 Server kernel: SMP: AP CPU #1 Launched! Oct 9 15:36:31 Server kernel: SMP: AP CPU #4 Launched! Oct 9 15:36:31 Server kernel: SMP: AP CPU #3 Launched! Oct 9 15:36:31 Server kernel: SMP: AP CPU #7 Launched! Oct 9 15:36:31 Server kernel: SMP: AP CPU #2 Launched! Oct 9 15:36:31 Server kernel: SMP: AP CPU #5 Launched! Oct 9 15:36:31 Server kernel: SMP: AP CPU #6 Launched! Oct 9 15:36:31 Server kernel: Trying to mount root from zfs:zroot Oct 9 15:36:33 Server kernel: igb0: link state changed to UP Oct 9 15:36:33 Server kernel: lagg0: link state changed to UP Oct 9 15:36:33 Server kernel: igb1: link state changed to UP Oct 9 15:36:49 Server ntpd[1286]: ntpd 4.2.4p5-a (1) Oct 9 15:36:56 Server ntpd[1287]: time reset +0.488748 s Oct 9 15:36:56 Server ntpd[1287]: kernel time sync status change 2001 Oct 9 15:37:48 Server login: ROOT LOGIN (toor) ON ttyv0 Oct 9 15:39:58 Server su: jeggema to toor on /dev/pts/0 Oct 9 15:45:42 Server kernel: isp1: Receive Error Oct 9 15:45:42 Server last message repeated 41 times Oct 9 15:45:56 Server login: ROOT LOGIN (toor) ON ttyv0 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032292000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x961 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff00321f0000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x962 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032286000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x963 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff00321ff000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x965 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032270000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x966 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032201000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x967 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff00321ec000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x968 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032229000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x969 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003223a000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x96a Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032277000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x96b Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff00321df000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x96c Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003226b000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x96e Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032294000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x96f Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032207000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x970 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003222c000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x971 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff001ed74000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x972 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032252000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x973 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003227a000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x974 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032250000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x976 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032264000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x977 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032260000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x978 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003221b000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x979 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032231000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x97a Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003226e000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x97b Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032227000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x97c Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032220000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x97d Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003227c000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x97e Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032233000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x97f Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032246000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x980 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032254000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x981 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032214000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x982 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032266000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x983 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003221d000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x984 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032259000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x985 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032272000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x987 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032211000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x988 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003225c000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x989 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003227e000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x98b Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032269000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x990 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff00321e9000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x993 Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff0032256000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x99f Oct 9 15:46:42 Server kernel: isp1: Chan 0 Abort Cmd for N-Port 0x0001 @ Port 0x01041d 0xffffff003220b000 Oct 9 15:46:42 Server kernel: (da7:isp1:0:0:0): watchdog timeout for handle 0x9a6 Oct 9 15:46:50 Server reboot: rebooted by toor Oct 9 15:47:03 Server kernel: isp1: Receive Error Oct 9 15:47:03 Server last message repeated 2 times Oct 9 15:47:06 Server syslogd: exiting on signal 15 # # FC-Switch, Raid 1+2 set to 8GBit, Server set to 8GBit, with 8GBit GBic # Oct 9 15:55:52 Server syslogd: kernel boot file is /boot/kernel/kernel Oct 9 15:55:52 Server kernel: ailbox Command 'INIT FIRMWARE' failed (COMMAND PARAMETER ERROR) Oct 9 15:55:52 Server kernel: isp0: Mailbox Command 'INIT FIRMWARE' failed (COMMAND PARAMETER ERROR) Oct 9 15:55:52 Server last message repeated 383 times Oct 9 15:55:52 Server kernel: isp1: Mailbox Command 'INIT FIRMWARE' failed (COMMAND PARAMETER ERROR) Oct 9 15:55:52 Server last message repeated 511 times Oct 9 15:55:52 Server kernel: da0 at mpt0 bus 0 target 1 lun 0 Oct 9 15:55:52 Server kernel: da0: Fixed Direct Access SCSI-5 device Oct 9 15:55:52 Server kernel: da0: 300.000MB/s transfers Oct 9 15:55:52 Server kernel: da0: Command Queueing enabled Oct 9 15:55:52 Server kernel: da0: 122104MB (250069680 512 byte sectors: 255H 63S/T 15566C) Oct 9 15:55:52 Server kernel: da1 at mpt0 bus 0 target 2 lun 0 Oct 9 15:55:52 Server kernel: da1: Fixed Direct Access SCSI-5 device Oct 9 15:55:52 Server kernel: da1: 300.000MB/s transfers Oct 9 15:55:52 Server kernel: da1: Command Queueing enabled Oct 9 15:55:52 Server kernel: da1: 122104MB (250069680 512 byte sectors: 255H 63S/T 15566C) Oct 9 15:55:52 Server kernel: da2 at mpt0 bus 0 target 3 lun 0 Oct 9 15:55:52 Server kernel: da2: Fixed Direct Access SCSI-5 device Oct 9 15:55:52 Server kernel: da2: 300.000MB/s transfers Oct 9 15:55:52 Server kernel: da2: Command Queueing enabled Oct 9 15:55:52 Server kernel: da2: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:55:52 Server kernel: da3 at mpt0 bus 0 target 5 lun 0 Oct 9 15:55:52 Server kernel: da3: Fixed Direct Access SCSI-5 device Oct 9 15:55:52 Server kernel: da3: 300.000MB/s transfers Oct 9 15:55:52 Server kernel: da3: Command Queueing enabled Oct 9 15:55:52 Server kernel: da3: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:55:52 Server kernel: da4 at mpt0 bus 0 target 6 lun 0 Oct 9 15:55:52 Server kernel: da4: Fixed Direct Access SCSI-5 device Oct 9 15:55:52 Server kernel: da4: 300.000MB/s transfers Oct 9 15:55:52 Server kernel: da4: Command Queueing enabled Oct 9 15:55:52 Server kernel: da4: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:55:52 Server kernel: da5 at mpt0 bus 0 target 7 lun 0 Oct 9 15:55:52 Server kernel: da5: Fixed Direct Access SCSI-5 device Oct 9 15:55:52 Server kernel: da5: 300.000MB/s transfers Oct 9 15:55:52 Server kernel: da5: Command Queueing enabled Oct 9 15:55:52 Server kernel: da5: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 15:55:52 Server kernel: SMP: AP CPU #1 Launched! Oct 9 15:55:52 Server kernel: SMP: AP CPU #7 Launched! Oct 9 15:55:52 Server kernel: SMP: AP CPU #3 Launched! Oct 9 15:55:52 Server kernel: SMP: AP CPU #4 Launched! Oct 9 15:55:52 Server kernel: SMP: AP CPU #2 Launched! Oct 9 15:55:52 Server kernel: SMP: AP CPU #5 Launched! Oct 9 15:55:52 Server kernel: SMP: AP CPU #6 Launched! Oct 9 15:55:52 Server kernel: Trying to mount root from zfs:zroot Oct 9 15:55:52 Server mountd[1180]: bad exports list line /data/users/jeggema Oct 9 15:55:52 Server mountd[1180]: bad exports list line /data/users/jsutmoe/Aussenlager Oct 9 15:55:52 Server mountd[1180]: bad exports list line /data/Software Oct 9 15:55:52 Server mountd[1180]: bad exports list line /data/KlimaWettreg Oct 9 15:55:52 Server mountd[1180]: bad exports list line /data/Temp Oct 9 15:55:52 Server ntpd[1264]: ntpd 4.2.4p5-a (1) Oct 9 15:55:53 Server kernel: igb0: link state changed to UP Oct 9 15:55:53 Server kernel: lagg0: link state changed to UP Oct 9 15:55:54 Server kernel: igb1: link state changed to UP Oct 9 15:56:14 Server login: ROOT LOGIN (toor) ON ttyv0 Oct 9 15:56:17 Server ntpd[1265]: time reset +0.944388 s Oct 9 15:56:17 Server ntpd[1265]: kernel time sync status change 2001 Oct 9 16:01:17 Server reboot: rebooted by toor Oct 9 16:01:17 Server syslogd: exiting on signal 15 # # FC-Switch, Raid 1+2, Server set to auto speed, with 4GBit GBic # Oct 9 16:16:37 Server syslogd: kernel boot file is /boot/kernel/kernel Oct 9 16:16:37 Server kernel: Copyright (c) 1992-2009 The FreeBSD Project. Oct 9 16:16:37 Server kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 9 16:16:37 Server kernel: The Regents of the University of California. All rights reserved. Oct 9 16:16:37 Server kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Oct 9 16:16:37 Server kernel: FreeBSD 8.0-RC1 #3: Fri Oct 9 15:27:23 CEST 2009 Oct 9 16:16:37 Server kernel: toor@Server:/usr/obj/usr/src/sys/KOMBJUDA Oct 9 16:16:37 Server kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Oct 9 16:16:37 Server kernel: CPU: Intel(R) Xeon(R) CPU E7440 @ 2.40GHz (2394.02-MHz K8-class CPU) Oct 9 16:16:37 Server kernel: Origin = "GenuineIntel" Id = 0x106d1 Stepping = 1 Oct 9 16:16:37 Server kernel: Features=0xbfebfbff Oct 9 16:16:37 Server kernel: Features2=0xce3bd Oct 9 16:16:37 Server kernel: AMD Features=0x20100800 Oct 9 16:16:37 Server kernel: AMD Features2=0x1 Oct 9 16:16:37 Server kernel: TSC: P-state invariant Oct 9 16:16:37 Server kernel: real memory = 103079215104 (98304 MB) Oct 9 16:16:37 Server kernel: avail memory = 99536936960 (94925 MB) Oct 9 16:16:37 Server kernel: ACPI APIC Table: <080808 APIC1448> Oct 9 16:16:37 Server kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs Oct 9 16:16:37 Server kernel: FreeBSD/SMP: 2 package(s) x 4 core(s) Oct 9 16:16:37 Server kernel: cpu0 (BSP): APIC ID: 0 Oct 9 16:16:37 Server kernel: cpu1 (AP): APIC ID: 1 Oct 9 16:16:37 Server kernel: cpu2 (AP): APIC ID: 2 Oct 9 16:16:37 Server kernel: cpu3 (AP): APIC ID: 3 Oct 9 16:16:37 Server kernel: cpu4 (AP): APIC ID: 8 Oct 9 16:16:37 Server kernel: cpu5 (AP): APIC ID: 9 Oct 9 16:16:37 Server kernel: cpu6 (AP): APIC ID: 10 Oct 9 16:16:37 Server kernel: cpu7 (AP): APIC ID: 11 Oct 9 16:16:37 Server kernel: ioapic0: Changing APIC ID to 12 Oct 9 16:16:37 Server kernel: ioapic1: Changing APIC ID to 13 Oct 9 16:16:37 Server kernel: ioapic0 irqs 0-23 on motherboard Oct 9 16:16:37 Server kernel: ioapic1 irqs 24-47 on motherboard Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: ispfw: registered firmware Oct 9 16:16:37 Server kernel: kbd1 at kbdmux0 Oct 9 16:16:37 Server kernel: acpi0: <080808 XSDT1448> on motherboard Oct 9 16:16:37 Server kernel: acpi0: [ITHREAD] Oct 9 16:16:37 Server kernel: acpi0: Power Button (fixed) Oct 9 16:16:37 Server kernel: acpi0: reservation of 0, a0000 (3) failed Oct 9 16:16:37 Server kernel: acpi0: reservation of 100000, bff00000 (3) failed Oct 9 16:16:37 Server kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Oct 9 16:16:37 Server kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Oct 9 16:16:37 Server kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Oct 9 16:16:37 Server kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Oct 9 16:16:37 Server kernel: pcib0: port 0xcf8-0xcff on acpi0 Oct 9 16:16:37 Server kernel: pci0: on pcib0 Oct 9 16:16:37 Server kernel: pcib1: irq 16 at device 1.0 on pci0 Oct 9 16:16:37 Server kernel: pci12: on pcib1 Oct 9 16:16:37 Server kernel: igb0: port 0xec00-0xec1f mem 0xfdee0000-0xfdefffff,0xfdec0000-0xfdedffff,0xfdebc000-0xfdebffff irq 16 at device 0.0 on pci12 Oct 9 16:16:37 Server kernel: igb0: Using MSIX interrupts with 3 vectors Oct 9 16:16:37 Server kernel: igb0: [ITHREAD] Oct 9 16:16:37 Server last message repeated 2 times Oct 9 16:16:37 Server kernel: igb0: Ethernet address: 00:30:48:d0:44:b6 Oct 9 16:16:37 Server kernel: igb1: port 0xe880-0xe89f mem 0xfde60000-0xfde7ffff,0xfde40000-0xfde5ffff,0xfdeb8000-0xfdebbfff irq 17 at device 0.1 on pci12 Oct 9 16:16:37 Server kernel: igb1: Using MSIX interrupts with 3 vectors Oct 9 16:16:37 Server kernel: igb1: [ITHREAD] Oct 9 16:16:37 Server last message repeated 2 times Oct 9 16:16:37 Server kernel: igb1: Ethernet address: 00:30:48:d0:44:b7 Oct 9 16:16:37 Server kernel: pcib2: irq 16 at device 2.0 on pci0 Oct 9 16:16:37 Server kernel: pci8: on pcib2 Oct 9 16:16:37 Server kernel: pcib3: irq 16 at device 0.0 on pci8 Oct 9 16:16:37 Server kernel: pci10: on pcib3 Oct 9 16:16:37 Server kernel: pcib4: at device 0.0 on pci10 Oct 9 16:16:37 Server kernel: pci11: on pcib4 Oct 9 16:16:37 Server kernel: mpt0: port 0xd800-0xd8ff mem 0xfdcfc000-0xfdcfffff,0xfdce0000-0xfdceffff irq 16 at device 0.0 on pci11 Oct 9 16:16:37 Server kernel: mpt0: [ITHREAD] Oct 9 16:16:37 Server kernel: mpt0: MPI Version=1.5.19.0 Oct 9 16:16:37 Server kernel: pcib5: at device 0.3 on pci8 Oct 9 16:16:37 Server kernel: pci9: on pcib5 Oct 9 16:16:37 Server kernel: pcib6: irq 16 at device 4.0 on pci0 Oct 9 16:16:37 Server kernel: pci7: on pcib6 Oct 9 16:16:37 Server kernel: pcib7: irq 16 at device 6.0 on pci0 Oct 9 16:16:37 Server kernel: pci3: on pcib7 Oct 9 16:16:37 Server kernel: pcib8: at device 0.0 on pci3 Oct 9 16:16:37 Server kernel: pci4: on pcib8 Oct 9 16:16:37 Server kernel: pcib9: at device 2.0 on pci4 Oct 9 16:16:37 Server kernel: pci6: on pcib9 Oct 9 16:16:37 Server kernel: em0: port 0xcc00-0xcc1f mem 0xfd7e0000-0xfd7fffff,0xfd7c0000-0xfd7dffff irq 19 at device 0.0 on pci6 Oct 9 16:16:37 Server kernel: em0: Using MSI interrupt Oct 9 16:16:37 Server kernel: em0: [FILTER] Oct 9 16:16:37 Server kernel: em0: Ethernet address: 00:15:17:aa:23:65 Oct 9 16:16:37 Server kernel: em1: port 0xc880-0xc89f mem 0xfd780000-0xfd79ffff,0xfd760000-0xfd77ffff irq 18 at device 0.1 on pci6 Oct 9 16:16:37 Server kernel: em1: Using MSI interrupt Oct 9 16:16:37 Server kernel: em1: [FILTER] Oct 9 16:16:37 Server kernel: em1: Ethernet address: 00:15:17:aa:23:64 Oct 9 16:16:37 Server kernel: pcib10: at device 4.0 on pci4 Oct 9 16:16:37 Server kernel: pci5: on pcib10 Oct 9 16:16:37 Server kernel: em2: port 0xbc00-0xbc1f mem 0xfd5e0000-0xfd5fffff,0xfd5c0000-0xfd5dffff irq 17 at device 0.0 on pci5 Oct 9 16:16:37 Server kernel: em2: Using MSI interrupt Oct 9 16:16:37 Server kernel: em2: [FILTER] Oct 9 16:16:37 Server kernel: em2: Ethernet address: 00:15:17:aa:23:67 Oct 9 16:16:37 Server kernel: em3: port 0xb880-0xb89f mem 0xfd580000-0xfd59ffff,0xfd560000-0xfd57ffff irq 16 at device 0.1 on pci5 Oct 9 16:16:37 Server kernel: em3: Using MSI interrupt Oct 9 16:16:37 Server kernel: em3: [FILTER] Oct 9 16:16:37 Server kernel: em3: Ethernet address: 00:15:17:aa:23:66 Oct 9 16:16:37 Server kernel: pci0: at device 8.0 (no driver attached) Oct 9 16:16:37 Server kernel: pcib11: irq 16 at device 28.0 on pci0 Oct 9 16:16:37 Server kernel: pci2: on pcib11 Oct 9 16:16:37 Server kernel: isp0: port 0xa800-0xa8ff mem 0xfd3fc000-0xfd3fffff irq 16 at device 0.0 on pci2 Oct 9 16:16:37 Server kernel: isp0: [ITHREAD] Oct 9 16:16:37 Server kernel: isp1: port 0xa400-0xa4ff mem 0xfd3f8000-0xfd3fbfff irq 17 at device 0.1 on pci2 Oct 9 16:16:37 Server kernel: isp1: [ITHREAD] Oct 9 16:16:37 Server kernel: pcib12: at device 30.0 on pci0 Oct 9 16:16:37 Server kernel: pci1: on pcib12 Oct 9 16:16:37 Server kernel: vgapci0: port 0x9000-0x90ff mem 0xd0000000-0xd7ffffff,0xfd1f0000-0xfd1fffff at device 1.0 on pci1 Oct 9 16:16:37 Server kernel: isab0: at device 31.0 on pci0 Oct 9 16:16:37 Server kernel: isa0: on isab0 Oct 9 16:16:37 Server kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 Oct 9 16:16:37 Server kernel: ata0: on atapci0 Oct 9 16:16:37 Server kernel: ata0: [ITHREAD] Oct 9 16:16:37 Server kernel: pci0: at device 31.3 (no driver attached) Oct 9 16:16:37 Server kernel: acpi_button0: on acpi0 Oct 9 16:16:37 Server kernel: atrtc0: port 0x70-0x71 irq 8 on acpi0 Oct 9 16:16:37 Server kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 Oct 9 16:16:37 Server kernel: uart0: [FILTER] Oct 9 16:16:37 Server kernel: uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 Oct 9 16:16:37 Server kernel: uart1: [FILTER] Oct 9 16:16:37 Server kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Oct 9 16:16:37 Server kernel: atkbd0: irq 1 on atkbdc0 Oct 9 16:16:37 Server kernel: kbd0 at atkbd0 Oct 9 16:16:37 Server kernel: atkbd0: [GIANT-LOCKED] Oct 9 16:16:37 Server kernel: atkbd0: [ITHREAD] Oct 9 16:16:37 Server kernel: orm0: at iomem 0xc0000-0xcafff,0xd3800-0xd47ff,0xd4800-0xd57ff on isa0 Oct 9 16:16:37 Server kernel: sc0: on isa0 Oct 9 16:16:37 Server kernel: sc0: VGA <16 virtual consoles, flags=0x300> Oct 9 16:16:37 Server kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Oct 9 16:16:37 Server kernel: ZFS filesystem version 13 Oct 9 16:16:37 Server kernel: ZFS storage pool version 13 Oct 9 16:16:37 Server kernel: Timecounters tick every 1.000 msec Oct 9 16:16:37 Server kernel: acd0: DVDROM at ata0-slave UDMA33 Oct 9 16:16:37 Server kernel: da0 at mpt0 bus 0 target 1 lun 0 Oct 9 16:16:37 Server kernel: da0: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da0: 300.000MB/s transfers Oct 9 16:16:37 Server kernel: da0: Command Queueing enabled Oct 9 16:16:37 Server kernel: da0: 122104MB (250069680 512 byte sectors: 255H 63S/T 15566C) Oct 9 16:16:37 Server kernel: da1 at mpt0 bus 0 target 2 lun 0 Oct 9 16:16:37 Server kernel: da1: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da1: 300.000MB/s transfers Oct 9 16:16:37 Server kernel: da1: Command Queueing enabled Oct 9 16:16:37 Server kernel: da1: 122104MB (250069680 512 byte sectors: 255H 63S/T 15566C) Oct 9 16:16:37 Server kernel: da2 at mpt0 bus 0 target 3 lun 0 Oct 9 16:16:37 Server kernel: da2: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da2: 300.000MB/s transfers Oct 9 16:16:37 Server kernel: da2: Command Queueing enabled Oct 9 16:16:37 Server kernel: da2: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 16:16:37 Server kernel: da3 at mpt0 bus 0 target 5 lun 0 Oct 9 16:16:37 Server kernel: da3: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da3: 300.000MB/s transfers Oct 9 16:16:37 Server kernel: da3: Command Queueing enabled Oct 9 16:16:37 Server kernel: da3: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 16:16:37 Server kernel: da4 at mpt0 bus 0 target 6 lun 0 Oct 9 16:16:37 Server kernel: da4: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da4: 300.000MB/s transfers Oct 9 16:16:37 Server kernel: da4: Command Queueing enabled Oct 9 16:16:37 Server kernel: da4: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 16:16:37 Server kernel: da5 at mpt0 bus 0 target 7 lun 0 Oct 9 16:16:37 Server kernel: da5: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da5: 300.000MB/s transfers Oct 9 16:16:37 Server kernel: da5: Command Queueing enabled Oct 9 16:16:37 Server kernel: da5: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Oct 9 16:16:37 Server kernel: da7 at isp1 bus 0 target 0 lun 0 Oct 9 16:16:37 Server kernel: da7: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da7: 400.000MB/s transfers Oct 9 16:16:37 Server kernel: da7: Command Queueing enabled Oct 9 16:16:37 Server kernel: da7: 13350582MB (27341991936 512 byte sectors: 255H 63S/T 1701960C) Oct 9 16:16:37 Server kernel: da6 at isp0 bus 0 target 0 lun 0 Oct 9 16:16:37 Server kernel: da6: Fixed Direct Access SCSI-5 device Oct 9 16:16:37 Server kernel: da6: 400.000MB/s transfers Oct 9 16:16:37 Server kernel: da6: Command Queueing enabled Oct 9 16:16:37 Server kernel: da6: 13350582MB (27341991936 512 byte sectors: 255H 63S/T 1701960C) Oct 9 16:16:37 Server kernel: SMP: AP CPU #1 Launched! Oct 9 16:16:37 Server kernel: SMP: AP CPU #4 Launched! Oct 9 16:16:37 Server kernel: SMP: AP CPU #2 Launched! Oct 9 16:16:37 Server kernel: SMP: AP CPU #6 Launched! Oct 9 16:16:37 Server kernel: SMP: AP CPU #3 Launched! Oct 9 16:16:37 Server kernel: SMP: AP CPU #5 Launched! Oct 9 16:16:37 Server kernel: SMP: AP CPU #7 Launched! Oct 9 16:16:37 Server kernel: Trying to mount root from zfs:zroot Oct 9 16:16:39 Server kernel: igb0: link state changed to UP Oct 9 16:16:39 Server kernel: lagg0: link state changed to UP Oct 9 16:16:39 Server kernel: igb1: link state changed to UP Oct 9 16:16:54 Server ntpd[1286]: ntpd 4.2.4p5-a (1) Oct 9 16:17:02 Server ntpd[1287]: time reset +1.056697 s Oct 9 16:17:02 Server ntpd[1287]: kernel time sync status change 2001 From urmas.lett at eenet.ee Wed Nov 4 14:18:45 2009 From: urmas.lett at eenet.ee (Urmas Lett) Date: Wed Nov 4 14:18:52 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> Message-ID: <4AF1891C.6010908@eenet.ee> gnukix@alltel.blackberry.com wrote: > I can send in more documentation later but I am seeing severe zfs performance issues with lighttpd. Same machine using UFS will push 1gbit or more but same content and traffic load can not hit 200mbit. Ufs does around 3 megabytes/sec IO at 800mbit network but zfs pushes the disks into the ground with 50+ megabytes/sec dusk i/o. No compression no atime no checksums on zfs and still same IO levels. Ufs with soft updates and atime on. Orders of magnitude more disk IO... Like zfs isn't using cache or isn't coalescing disk reads or both. > > Has anyone else seen this or have any recommendations? Lighttpd config remains exactly the same as well FYI. Only difference is ufs vs zfs. Hi, I can confirm this on FreeBSD 7.2-STABLE. first run: :~# wget -O /dev/null http://192.168.1.1/1000m.bin --2009-11-04 15:36:15-- http://192.168.1.1/1000m.bin Connecting to 192.168.1.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1048576000 (1000M) [application/octet-stream] Saving to: `/dev/null' 100%[====================================>] 1,048,576,000 17.0M/s in 81s 2009-11-04 15:37:36 (12.3 MB/s) - `/dev/null' saved [1048576000/1048576000] second run is even slower, cannot wait till end: :~# wget -O /dev/null http://192.168.1.1/1000m.bin --2009-11-04 15:40:00-- http://192.168.1.1/1000m.bin Connecting to 192.168.1.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1048576000 (1000M) [application/octet-stream] Saving to: `/dev/null' 71% [==========================> ] 752,173,056 2.10M/s eta 2m 0s ^C After changing in lighttpd.conf server.network-backend = "writev" first run: :~# wget -O /dev/null http://192.168.1.1/1000m.bin --2009-11-04 15:47:51-- http://192.168.1.1/1000m.bin Connecting to 192.168.1.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1048576000 (1000M) [application/octet-stream] Saving to: `/dev/null' 100%[====================================>] 1,048,576,000 44.1M/s in 27s 2009-11-04 15:48:18 (37.2 MB/s) - `/dev/null' saved [1048576000/1048576000] second & third run: :~# wget -O /dev/null http://192.168.1.1/1000m.bin --2009-11-04 15:48:20-- http://192.168.1.1/1000m.bin Connecting to 192.168.1.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1048576000 (1000M) [application/octet-stream] Saving to: `/dev/null' 100%[====================================>] 1,048,576,000 788M/s in 1.3s 2009-11-04 15:48:21 (788 MB/s) - `/dev/null' saved [1048576000/1048576000] :~# wget -O /dev/null http://192.168.1.1/1000m.bin --2009-11-04 15:48:24-- http://192.168.1.1/1000m.bin Connecting to 192.168.1.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1048576000 (1000M) [application/octet-stream] Saving to: `/dev/null' 100%[====================================>] 1,048,576,000 910M/s in 1.1s 2009-11-04 15:48:25 (910 MB/s) - `/dev/null' saved [1048576000/1048576000] I have Intel 10GbE PCI-Express directly connected between two servers. -- Urmas Lett Tel: +(372) 7 302 110 Fax: +(372) 7 302 111 E-Mail: urmas.lett@eenet.ee From jacob at whotookspaz.org Wed Nov 4 14:27:59 2009 From: jacob at whotookspaz.org (Jacob Myers) Date: Wed Nov 4 14:28:06 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> Message-ID: <4AF18F3A.50804@whotookspaz.org> Jaime Bozza wrote: > From: Arnaud Houdelette [mailto:arnaud.houdelette@tzim.net] >> I haven't tried larger files - Maybe the boundary is different on amd64? Doing some quick tests >> right now, I was able to upload a 100MB file without a problem, but this is an AMD64 system with SMP, >> plus the filesystem is all ZFS, so there are too many things different. I'll have to setup a system >> that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before I can say I'm not having a >> problem there. >>> Jaime >>> >> I had the same issue using 7.1 amd64, with ZFS, no SMP. >> Not really sure what is the size boundary. I can't really test either, >> as the machine is remote. >> But I confirm that each tentative upload of certain relatively 'big' >> files (around 1MB) with wordpress hanged the system before I switched >> from sendfile to writev. >> >> I might do some test on amd64 7.2 with no SMP if it can be of any use ? >> >> Arnaud > > I was able to duplicate the problem on 7.2-STABLE amd64 no SMP - Problem didn't seem to happen with SMP on. While I wasn't able to get a crash dump, the crash looked similar. > > Jaime > FWIW, there was a fix committed for this: http://svn.freebsd.org/viewvc/base?view=revision&revision=198853 See if it helps. -- Jacob Myers | Website: http://whotookspaz.org Network Admin, Wilcox Technologies | Public key: 186A424A Using FreeBSD since 2007 | Public shell: http://bit.ly/42iGCR Answer a fool according to his folly, lest he be wise in his own conceit -- Proverbs, 26:5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091104/6f98fa64/signature.pgp From kohls at e.kohls.com Wed Nov 4 17:16:49 2009 From: kohls at e.kohls.com (Kohls.com) Date: Wed Nov 4 17:16:56 2009 Subject: 50% Off SALE + Extra 15% Off Holiday Decor Message-ID: To view the HTML version of this e-mail, copy and paste the link below into the Address field of your Internet browser: http://e.kohls.com/a/tBK79ULBBZVhBB724FRBVGUbCB$/kohl1?t=BK79ULBBZVhBB724FRBVGUbCB$&email=freebsd-stable@freebsd.org&i_equity=0 ************************************************************************ 99? Standard Shipping on every item!* Surcharges still apply. ************************************************************************ Take an EXTRA 15% Off** Entire Stock Holiday Decor! Simply enter Promo Code HOLIDAYHOME when you checkout online now through November 5 during our 50% Off Sale! 50% Off Selected Holiday Dinnerware & Table Linens 50% Off Selected Candles & Decorative Accents 50% Off Entire Stock St. Nicholas Square Trim-A-Tree & Home Decor ************************************************************************ Skechers Shape-Ups Shape up while you walk! Designed to: -Promote weight loss -Tone muscles -Improve posture ************************************************************************ Find Kohl's on Facebook! Become a fan to connect with friends and get insider info. ************************************************************************ *Surcharges may apply due to size, weight or special handling required. If your item has a surcharge, it will appear on the product page. **OFFER IS VALID ONLINE ONLY. Offer is not valid in conjunction with any other percent-off discounts. Offer is nontransferable. Promo Code must be entered during checkout on Kohls.com to receive discount. Offer good on all sale-, regular- and clearance-priced merchandise. Offer not valid for price adjustments on prior purchases, on gift card purchases, for payment on a Kohl's Charge account or in conjunction with any other percent-off discounts, including the senior citizen discount. Offer also not valid on purchases of Kohl's Cares for Kids merchandise or other charitable items. Excludes sales tax. This mailbox is unattended, so please do not reply to this message. Instead, e-mail us at myaccount.help@kohls.com, or write to us at Kohl's Department Stores, Attention: Customer Service, N54 W13600 Woodale Drive, Menomonee Falls, WI 53051. If you no longer wish to receive e-mails from Kohls.com, unsubscribe by pasting this link into the Address field of your Internet browser: http://e.kohls.com/a/tBK79ULBBZVhBB724FRBVGUbCB$/kohl14?email=freebsd-stable@freebsd.org&email=freebsd-stable@freebsd.org Please allow up to seven days for your e-mail address to be removed. 99? Standard Shipping per item offer good now through November 5, 2009. 50% Off Sale prices good now through November 5, 2009. Extra 15% Off Holiday Decor offer good now through November 5, 2009. From pyunyh at gmail.com Wed Nov 4 17:52:55 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Nov 4 17:53:02 2009 Subject: Broadcom BCM5715 not coming up In-Reply-To: <7dc029620911040434v7145b8afue945f2e3930dfb75@mail.gmail.com> References: <7dc029620911040434v7145b8afue945f2e3930dfb75@mail.gmail.com> Message-ID: <20091104175215.GO1256@michelle.cdnetworks.com> On Wed, Nov 04, 2009 at 03:34:49PM +0300, Mike Barnard wrote: > Hi, > > I am experiencing a weird problem on an HP ProLiant BL480c G1 with a > Broadcom Dual Gigabit network card. > > For some reason, it wont come up. I have tried it with different media > speeds, options but nothing. I upgraded my sources, recompiled and installed Would you give me more details? Which interface does not show up? dmesg output shows your all 4 controllers were attached successfully. You mean you see no link even if driver recognized the controller? > from FreeBSD 7.1-PRERELEASE to 7.2-STABLE but I get the same error. > From dclark at engr.scu.edu Wed Nov 4 23:07:30 2009 From: dclark at engr.scu.edu (Dorr H. Clark) Date: Wed Nov 4 23:07:37 2009 Subject: gdb/libkvm problem - can someone explain this? In-Reply-To: Message-ID: With FreeBSD 4.x, gdb -k is able to read and interpret the last 4 bytes of a page (4k) boundary. In BSD 6.x/7.x/8.x using the kgdb program, if one issues the kgdb command: (gdb) x /x 0xcbed8ffd An "invalid address" error is returned. However, if one issues the command: (gdb) x /10x 0xcbed8ff0 it is able to read the memory (and past) just fine. The following patch returns the usr/src/lib/libkvm/kvm_i386.c behavior closer to the BSD4.x version and seems to remedy this situation. @@ -289,11 +289,13 @@ #define PG_FRAME4M (~PAGE4M_MASK) pde_pa = ((u_long)pde & PG_FRAME4M) + (va & PAGE4M_MASK); s = _kvm_pa2off(kd, pde_pa, &ofs); +#if 0 if (s < sizeof pde) { _kvm_syserr(kd, kd->program, "_kvm_vatop: pde_pa not found"); goto invalid; } +#endif *pa = ofs; return (NBPDR - (va & PAGE4M_MASK)); } Does anyone see any problem or have any comments about this? Paul Lai Engineer Dorr H. Clark Advisor Graduate School of Engineering Santa Clara University Santa Clara, CA. http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/libkvm_problem.txt From egrosbein at rdtc.ru Thu Nov 5 06:32:20 2009 From: egrosbein at rdtc.ru (Eugene Grosbein) Date: Thu Nov 5 06:32:28 2009 Subject: x11/nvidia-driver cannot obtain EDID under 8.0-BETA3/i386 In-Reply-To: <200909021559.31093.fbsd.multimedia@rachie.is-a-geek.net> References: <20090828135029.GA21544@svzserv.kemerovo.su> <200909021559.31093.fbsd.multimedia@rachie.is-a-geek.net> Message-ID: <4AF26B7F.2020401@rdtc.ru> Mel Flynn wrote: >> Fresh install of 8.0-BETA2 upgraded to 8.0-BETA3 using source, >> x.org installed from fresh ports tree. It cannot read EDID from >> Samsung 959NF CRT monitor. The same time, it can read EDID under 7.2-STABLE >> just fine. I've tried older nvidia-driver-180.60 (downgrading port) >> and current port's version 185.18.29, no change. >> >> (WW) NVIDIA(GPU-0): Unable to read EDID for display device CRT-1 Just for archives: Samsung 959NF has two inputs, D-Sub and BNC. For D-Sub, it presents EDID and it does not for BNC that I used. So, the problem was with monitor connection, not with FreeBSD nor nvidia-driver. Eugene Grosbein From gary.jennejohn at freenet.de Thu Nov 5 09:12:32 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Nov 5 09:12:44 2009 Subject: gdb/libkvm problem - can someone explain this? In-Reply-To: References: Message-ID: <20091105101226.5c6ef961@ernst.jennejohn.org> On Wed, 4 Nov 2009 15:06:17 -0800 (PST) "Dorr H. Clark" wrote: > > With FreeBSD 4.x, gdb -k is able to read and interpret > the last 4 bytes of a page (4k) boundary. > > In BSD 6.x/7.x/8.x using the kgdb program, > if one issues the kgdb command: > (gdb) x /x 0xcbed8ffd > An "invalid address" error is returned. > This is only 3 bytes - d, e, f. Try it with 0xcbed8ffc. BTW you got a little carried away with cross posting. --- Gary Jennejohn From jhb at freebsd.org Thu Nov 5 13:56:37 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 5 13:56:50 2009 Subject: gdb/libkvm problem - can someone explain this? In-Reply-To: References: Message-ID: <200911050856.13188.jhb@freebsd.org> On Wednesday 04 November 2009 6:06:17 pm Dorr H. Clark wrote: > > With FreeBSD 4.x, gdb -k is able to read and interpret > the last 4 bytes of a page (4k) boundary. > > In BSD 6.x/7.x/8.x using the kgdb program, > if one issues the kgdb command: > (gdb) x /x 0xcbed8ffd > An "invalid address" error is returned. > > However, if one issues the command: > (gdb) x /10x 0xcbed8ff0 > it is able to read the memory (and past) just fine. > > The following patch returns the usr/src/lib/libkvm/kvm_i386.c > behavior closer to the BSD4.x version and seems to remedy this situation. > > @@ -289,11 +289,13 @@ > #define PG_FRAME4M (~PAGE4M_MASK) > pde_pa = ((u_long)pde & PG_FRAME4M) + (va & PAGE4M_MASK); > s = _kvm_pa2off(kd, pde_pa, &ofs); > +#if 0 > if (s < sizeof pde) { > _kvm_syserr(kd, kd->program, > "_kvm_vatop: pde_pa not found"); > goto invalid; > } > +#endif > *pa = ofs; > return (NBPDR - (va & PAGE4M_MASK)); > } > > Does anyone see any problem or have any comments about this? How about this. It needs to fail if the page is not found at all, but this should fix your edge case. It also matches what kvm_amd64.c does. I think this was just a copy and paste bug. Index: kvm_i386.c =================================================================== --- kvm_i386.c (revision 198888) +++ kvm_i386.c (working copy) @@ -295,9 +295,9 @@ #define PG_FRAME4M (~PAGE4M_MASK) pde_pa = ((u_long)pde & PG_FRAME4M) + (va & PAGE4M_MASK); s = _kvm_pa2off(kd, pde_pa, &ofs); - if (s < sizeof pde) { - _kvm_syserr(kd, kd->program, - "_kvm_vatop: pde_pa not found"); + if (s == 0) { + _kvm_err(kd, kd->program, + "_kvm_vatop: 4MB page address not in dump"); goto invalid; } *pa = ofs; @@ -391,9 +391,9 @@ #define PG_FRAME2M (~PAGE2M_MASK) pde_pa = ((u_long)pde & PG_FRAME2M) + (va & PAGE2M_MASK); s = _kvm_pa2off(kd, pde_pa, &ofs); - if (s < sizeof pde) { - _kvm_syserr(kd, kd->program, - "_kvm_vatop_pae: pde_pa not found"); + if (s == 0) { + _kvm_err(kd, kd->program, + "_kvm_vatop: 2MB page address not in dump"); goto invalid; } *pa = ofs; -- John Baldwin From chris# at 1command.com Thu Nov 5 22:44:34 2009 From: chris# at 1command.com (Chris H) Date: Thu Nov 5 22:44:40 2009 Subject: make: Max recursion level (500) exceeded.: Resource temporarily unavailable Message-ID: <1351d34267ef212d4fc02a9c8d5d9aff.HRCIM@webmail.1command.com> Greetings, I recieved the error: make: Max recursion level (500) exceeded.: Resource temporarily unavailable when attempting to perform: make install && make clean, in graphics/gimp-app How to overcome? Some context follows: ===> Found saved configuration for gimp-2.6.6,2 ===> Extracting for gimp-2.6.6,2 ===> Patching for gimp-2.6.6,2 ===> Configuring for gimp-2.6.6,2 ===> Installing for gimp-2.6.6,2 ===> gimp-2.6.6,2 depends on executable: gimp-2.6 - not found ===> Verifying install for gimp-2.6 in /usr/ports/graphics/gimp-app ===> Extracting for gimp-app-2.6.6_3,1 => MD5 Checksum OK for gimp-2.6.6.tar.bz2. => SHA256 Checksum OK for gimp-2.6.6.tar.bz2. ===> Patching for gimp-app-2.6.6_3,1 ===> gimp-app-2.6.6_3,1 depends on package: libtool>=2.2 - found ===> Applying FreeBSD patches for gimp-app-2.6.6_3,1 ===> gimp-app-2.6.6_3,1 depends on file: /usr/local/libdata/pkgconfig/iso-codes.pc - found ===> gimp-app-2.6.6_3,1 depends on executable: gmake - found ===> gimp-app-2.6.6_3,1 depends on file: /usr/local/libdata/pkgconfig/xpm.pc - found ===> gimp-app-2.6.6_3,1 depends on file: /usr/local/libdata/pkgconfig/xmu.pc - found ===> gimp-app-2.6.6_3,1 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===> gimp-app-2.6.6_3,1 depends on package: libtool>=2.2 - found ===> gimp-app-2.6.6_3,1 depends on file: /usr/local/bin/intltool-extract - found ===> gimp-app-2.6.6_3,1 depends on executable: pkg-config - found ===> gimp-app-2.6.6_3,1 depends on executable: update-desktop-database - found ===> gimp-app-2.6.6_3,1 depends on shared library: png.5 - found ===> gimp-app-2.6.6_3,1 depends on shared library: jpeg.10 - found ===> gimp-app-2.6.6_3,1 depends on shared library: tiff.4 - found ===> gimp-app-2.6.6_3,1 depends on shared library: lcms.1 - found ===> gimp-app-2.6.6_3,1 depends on shared library: gegl-0.0.22 - found ===> gimp-app-2.6.6_3,1 depends on shared library: gimp-2.0.0 - not found ===> Verifying install for gimp-2.0.0 in /usr/ports/graphics/gimp-app ... line #7998 ... ===> Verifying install for gimp-2.0.0 in /usr/ports/graphics/gimp-app make: Max recursion level (500) exceeded.: Resource temporarily unavailable *** Error code 2 Stop in /usr/ports/graphics/gimp-app. *** Error code 1 Stop in /usr/ports/graphics/gimp-app. *** Error code 1 Thanks for all your time and consideration. --Chris uname FreeBSD 7.2-RELEASE-p4 #0: Sun Nov 1 18:44:29 PST 2009 source/ports from cvs of same day. From tonix at interazioni.it Thu Nov 5 23:19:39 2009 From: tonix at interazioni.it (Tonix (Antonio Nati)) Date: Thu Nov 5 23:19:47 2009 Subject: Features in 8.0? Message-ID: <4AF35D7D.7010807@interazioni.it> I'd like to know if these features are available in FreeBSD 8.0. * advanced routing (I miss the possibility to define routes based on sender IPs) * carpdev Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From thomas at FreeBSD.ORG Fri Nov 6 00:36:19 2009 From: thomas at FreeBSD.ORG (Thomas Quinot) Date: Fri Nov 6 00:36:27 2009 Subject: .zfs snapshot dir disappears and a crash later on, while umounting (8.0-RC1) In-Reply-To: References: Message-ID: <20091106003617.GA1908@melamine.cuivre.fr.eu.org> * Gy?rgy Vilmos, 2009-06-11 : > Subject: .zfs snapshot dir disappears and a crash later on, while > umounting For the record, I got the same symptom here on 8.0-RC1. > #7 0xffffffff807ba96e in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:209 > #8 0xffffffff80517925 in _sx_xlock (sx=0xa0, opts=0, > file=0xffffffff80f045e8 "/usr/src/sys/modules/zfs/../../cddl/contrib/ > opensolaris/uts/common/fs/zfs/zfs_ctldir.c", > line=1288) at atomic.h:143 > #9 0xffffffff80e97e55 in zfsctl_umount_snapshots (vfsp=Variable > "vfsp" is not available. > ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ Clearly looks like something in the .zfs structure gets botched at some point... I'll keep the crash dump for a while, if more information is needed please let me know. Thomas. melamine.cuivre.fr.eu.org dumped core - see /var/crash/vmcore.0 Fri Nov 6 01:23:21 CET 2009 FreeBSD melamine.cuivre.fr.eu.org 8.0-RC1 FreeBSD 8.0-RC1 #0: Tue Oct 6 19:43:29 UTC 2009 root@melamine2.cuivre.fr.eu.org:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <6>ifa_del_loopback_route: deletion failed <5>tun2: link state changed to DOWN <118>Nov 6 00:16:38 melamine syslogd: exiting on signal 15 info: [drm] Resetting GPU Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xa8 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8058cbf5 stack pointer = 0x28:0xffffff815d480970 frame pointer = 0x28:0xffffff815d480980 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 41907 (reboot) trap number = 12 panic: page fault cpuid = 0 Uptime: 15d10h25m49s Physical memory: 12270 MB Dumping 5655 MB: 5640 5624 5608 5592 5576 5560 5544 5528 5512 5496 5480 5464 5448 5432 5416 5400 5384 5368 5352 5336 5320 5304 5288 5272 5256 5240 5224 5208 5192 5176 5160 5144 5128 5112 5096 5080 5064 5048 5032 5016 5000 4984 4968 4952 4936 4920 4904 4888 4872 4856 4840 4824 4808 4792 4776 4760 4744 4728 4712 4696 4680 4664 4648 4632 4616 4600 4584 4568 4552 4536 4520 4504 4488 4472 4456 4440 4424 4408 4392 4376 4360 4344 4328 4312 4296 4280 4264 4248 4232 4216 4200 4184 4168 4152 4136 4120 4104 4088 4072 4056 4040 4024 4008 3992 3976 3960 3944 3928 3912 3896 3880 3864 3848 3832 3816 3800 3784 3768 3752 3736 3720 3704 3688 3672 3656 3640 3624 3608 3592 3576 3560 3544 3528 3512 3496 3480 3464 3448 3432 3416 3400 3384 3368 3352 3336 3320 3304 3288 3272 3256 3240 3224 3208 3192 3176 3160 3144 3128 3112 3096 3080 3064 3048 3032 3016 3000 2984 2968 2952 2936 2920 2904 2888 2872 2856 2840 2824 2808 2792 2776 2760 2744 2728 2712 2696 2680 2664 2648 2632 2616 2600 2584 2568 2552 2536 2520 2504 2488 2472 2456 2440 2424 2408 2392 2376 2360 2344 2328 2312 2296 2280 2264 2248 2232 2216 2200 2184 2168 2152 2136 2120 2104 2088 2072 2056 2040 2024 2008 1992 1976 1960 1944 1928 1912 1896 1880 1864 1848 1832 1816 1800 1784 1768 1752 1736 1720 1704 1688 1672 1656 1640 1624 1608 1592 1576 1560 1544 1528 1512 1496 1480 1464 1448 1432 1416 1400 1384 1368 1352 1336 1320 1304 1288 1272 1256 1240 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/accf_data.ko...Reading symbols from /boot/kernel/accf_data.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_data.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff80584f19 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff8058534c in panic (fmt=0xffffffff8092c24c "%s") at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff80865ad8 in trap_fatal (frame=0xffffff000625c390, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0xffffffff80865ea4 in trap_pfault (frame=0xffffff815d4808c0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:768 #5 0xffffffff80866794 in trap (frame=0xffffff815d4808c0) at /usr/src/sys/amd64/amd64/trap.c:494 #6 0xffffffff8084cb33 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #7 0xffffffff8058cbf5 in _sx_xlock (sx=0x90, opts=0, file=0xffffffff80efcca8 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c", line=1336) at atomic.h:147 #8 0xffffffff80e8ec75 in zfsctl_umount_snapshots (vfsp=Variable "vfsp" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:1336 #9 0xffffffff80e9b559 in zfs_umount (vfsp=0xffffff0006a50000, fflag=524288) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1017 #10 0xffffffff80609ffa in dounmount (mp=0xffffff0006a50000, flags=524288, td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_mount.c:1290 #11 0xffffffff8060d962 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:3141 #12 0xffffffff8058519a in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:401 #13 0xffffffff8058543c in reboot (td=0xffffff000625c390, uap=0xffffff815d480bf0) at /usr/src/sys/kern/kern_shutdown.c:173 #14 0xffffffff80866116 in syscall (frame=0xffffff815d480c80) at /usr/src/sys/amd64/amd64/trap.c:984 #15 0xffffffff8084ce11 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #16 0x000000080078f83c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From dclark at engr.scu.edu Fri Nov 6 01:06:24 2009 From: dclark at engr.scu.edu (Dorr H. Clark) Date: Fri Nov 6 01:06:44 2009 Subject: resource leak in fifo_vnops.c: 6.x/7.x/8.x In-Reply-To: Message-ID: We believe we have identified a significant resource leak present in 6.x, 7.x, and 8.x. We believe this is a regression versus FreeBSD 4.x which appears to do the Right Thing (tm). We have a test program (see below) which will run the system out of sockets by repeated exercise of the failing code path in the kernel. Our proposed fix is applied to the file usr/src/sys/fs/fifofs/fifo_vnops.c @@ -237,6 +237,8 @@ if (ap->a_mode & FWRITE) { if ((ap->a_mode & O_NONBLOCK) && fip->fi_readers == 0) { mtx_unlock(&fifo_mtx); + /* Exclusive VOP lock is held - safe to clean */ + fifo_cleanup(vp); return (ENXIO); } fip->fi_writers++; Test program follows. We welcome feedback on this proposed fix. Chitti Nimmagadda Engineer Dorr H. Clark Advisor Graduate School of Engineering Santa Clara University Santa Clara, CA. A test program which reveals the issue is presented here: #include #include #include #include #include #include #include #include #include #include #define FIFOPATH "/tmp/fifobug.debug" void getsysctl(name, ptr, len) const char *name; void *ptr; size_t len; { size_t nlen = len; if (sysctlbyname(name, ptr, &nlen, NULL, 0) != 0) { perror("sysctl"); printf("name: %s\n", name); exit(-1); } if (nlen != len) { printf("sysctl(%s...) expected %lu, got %lu", name, (unsigned long)len, (unsigned long)nlen); exit(-2); } } main(int argc, char *argv[]) { int acnt = 0, bcnt = 0, maxcnt; int fd; unsigned int maxiter; int notdone = 1; int i= 0; getsysctl("kern.ipc.maxsockets", &maxcnt, sizeof(maxcnt)); if (argc == 2) { maxiter = atoi(argv[1]); } else { maxiter = maxcnt*2; } unlink(FIFOPATH); printf("Max sockets: %d\n", maxcnt); printf("FIFO %s will be created, opened, deleted %d times\n", FIFOPATH, maxiter); getsysctl("kern.ipc.numopensockets", &bcnt, sizeof(bcnt)); while(notdone && (i++ < maxiter)) { if (mkfifo(FIFOPATH, 0) == 0) { chmod(FIFOPATH, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH); } fd = open(FIFOPATH, O_WRONLY|O_NONBLOCK); if ((fd <= 0) && (errno != ENXIO)) { notdone = 0; } unlink(FIFOPATH); } getsysctl("kern.ipc.numopensockets", &acnt, sizeof(acnt)); printf("Open Sockets: Before Test: %d, After Test: %d, diff: %d\n", bcnt, acnt, acnt - bcnt); if (notdone) { printf("FIFO/socket bug is fixed\n"); exit(0); } else { printf("FIFO/socket bug is NOT fixed\n"); exit(-1); } } http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/fifo_socket_leak.txt From sobomax at FreeBSD.org Fri Nov 6 01:41:27 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Fri Nov 6 01:41:39 2009 Subject: em0: watchdog timeout when communicating to windows using 9K MTU Message-ID: <4AF3795F.7010103@FreeBSD.org> Hi, My em0 interface repeatedly hangs up with watchdog timeout when communicating to the windows host at MTU 9K. [sobomax@pioneer ~]$ grep em0 /var/run/dmesg.boot em0: port 0xecc0-0xecdf mem 0xfe6e0000-0xfe6fffff,0xfe6d9000-0xfe6d9fff irq 21 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:22:19:32:87:2f [sobomax@pioneer ~]$ uname -a FreeBSD pioneer.sippysoft.com 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Sun Oct 4 03:08:04 PDT 2009 root@pioneer.sippysoft.com:/usr/obj/usr/src/sys/PIONEER amd64 [sobomax@pioneer ~]$ ifconfig em0 em0: flags=8843 metric 0 mtu 9000 options=98 ether 00:22:19:32:87:2f inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 inet6 fec0::1 prefixlen 64 media: Ethernet autoselect (1000baseTX ) status: active [sobomax@pioneer ~]$ dmesg | grep watchd em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting em0: watchdog timeout -- resetting I have managed to make a packet capture right at the time when hang happens. It appears to be that either "MAC Pause" or "TCP Segment of reassembled PDU" is the last packet that goes through before the interface hangs. Here is the screenshot, if somebody wants to take closer look at the actual packets please let me know. http://sobomax.sippysoft.com/~sobomax/ScreenShot527.png Turning off TSO and TXCSUM/RXCSUM has not helped. Bringing MTU down to 1,500 resolved the problem immediately. I have had the same problem happening several times in the past (although I initially attributed it to the bad cable or something like that), so it's definitely not on-off issue. Given popularity of intel/pro chips in today's computers it look like quite serious issue to me. Any help is greatly appreciated. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From m.seaman at infracaninophile.co.uk Fri Nov 6 08:19:32 2009 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Fri Nov 6 08:19:39 2009 Subject: Features in 8.0? In-Reply-To: <4AF35D7D.7010807@interazioni.it> References: <4AF35D7D.7010807@interazioni.it> Message-ID: <4AF3DC05.3010408@infracaninophile.co.uk> Tonix (Antonio Nati) wrote: > I'd like to know if these features are available in FreeBSD 8.0. > > * advanced routing (I miss the possibility to define routes based > on sender IPs) > * carpdev Yes to both, if you enable pf. The advanced routing I think you're asking about is generally described as 'policy based routing' -- look for the documentation on the 'route-to' keyword in pf rulesets: http://openbsd.org/faq/pf/pools.html#outgoing If you implement CARP on a firewall pair, then you will need a carp0 pseudo interface -- this can be created and configured in /etc/rc.conf like so: cloned_interfaces="carp0" ifconfig_carp0="vhid 100 pass ~not~telling~you~ 192.0.2.1/24" FreeBSD-8.0 now also has the capability of using a per-application routing table, so you can change the routes for (say) apache or squid independently of what applies for the rest of the system. See setfib(1) for more information, plus recent examples of implementing this in RC scripts on the ports mailing list. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091106/71f3e4c8/signature.pgp From attilio at freebsd.org Fri Nov 6 08:57:22 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Nov 6 08:57:29 2009 Subject: resource leak in fifo_vnops.c: 6.x/7.x/8.x In-Reply-To: References: Message-ID: <3bbf2fe10911060057t5ebfb330n486c80018826fa93@mail.gmail.com> 2009/11/6 Dorr H. Clark : > > > We believe we have identified a significant resource leak > present in 6.x, 7.x, and 8.x. We believe this is a regression > versus FreeBSD 4.x which appears to do the Right Thing (tm). > > We have a test program (see below) which will run the system > out of sockets by repeated exercise of the failing code > path in the kernel. > > Our proposed fix is applied to the file usr/src/sys/fs/fifofs/fifo_vnops.c > > > @@ -237,6 +237,8 @@ > if (ap->a_mode & FWRITE) { > if ((ap->a_mode & O_NONBLOCK) && fip->fi_readers == 0) { > mtx_unlock(&fifo_mtx); > + /* Exclusive VOP lock is held - safe to clean */ > + fifo_cleanup(vp); > return (ENXIO); > } > fip->fi_writers++; I think it should also check that fip->if_writers == 0 (and possibly the checks within fifo_cleanup() should just be assertions, but that's orthogonal someway) and the comment is not needed. Attilio -- Peace can only be achieved by understanding - A. Einstein From tonix at interazioni.it Fri Nov 6 09:29:47 2009 From: tonix at interazioni.it (Tonix (Antonio Nati)) Date: Fri Nov 6 09:29:54 2009 Subject: Features in 8.0? In-Reply-To: <4AF3DC05.3010408@infracaninophile.co.uk> References: <4AF35D7D.7010807@interazioni.it> <4AF3DC05.3010408@infracaninophile.co.uk> Message-ID: <4AF3EC86.7010506@interazioni.it> Matthew Seaman ha scritto: > Tonix (Antonio Nati) wrote: >> I'd like to know if these features are available in FreeBSD 8.0. >> >> * advanced routing (I miss the possibility to define routes based >> on sender IPs) >> * carpdev > > Yes to both, if you enable pf. The advanced routing I think you're > asking > about is generally described as 'policy based routing' -- look for the > documentation on the 'route-to' keyword in pf rulesets: > > http://openbsd.org/faq/pf/pools.html#outgoing > > If you implement CARP on a firewall pair, then you will need a carp0 > pseudo interface -- this can be created and configured in /etc/rc.conf > like > so: > > cloned_interfaces="carp0" > > ifconfig_carp0="vhid 100 pass ~not~telling~you~ 192.0.2.1/24" > > FreeBSD-8.0 now also has the capability of using a per-application > routing > table, so you can change the routes for (say) apache or squid > independently > of what applies for the rest of the system. See setfib(1) for more > information, plus recent examples of implementing this in RC scripts on > the ports mailing list. > As far as I read, it is no to both. About routes, if I type a "route" command I will not be able these routes. I hope to add a route with a command like "route add --from 192.168.16.0/24 ....", and I hope I can see all the routes in the system with the "route" command, without need to have two separate commands to merge. About carpdev, I already know carp is implemented, but up to now the OpenSBD carpdev, which let a virtual IP to bind an interface, is not implemented. The FreeBSD way forces to have one "fixed" ip for each interface on which we need a virtual IP. Impossible for complex networks. Thanks, Tonino > Cheers, > > Matthew > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From Johan at double-l.nl Fri Nov 6 15:27:02 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Fri Nov 6 15:27:09 2009 Subject: Buildworld on 8.0 RC2 fails. Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57187@w2003s01.double-l.local> I have 4 macines running FreeBSD 8.0RC2 , which where last updated on 5/11/2009 I have csuped the src today, and on the buildworld cycle (make kernel ) they all error out with the following error!! cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 - g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-protot ypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex tensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DH AVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-fra me-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-s se3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestan ding -fstack-protector -Werror /usr/src/sys/amd64/amd64/fpu.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 - g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-protot ypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex tensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DH AVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-fra me-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-s se3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestan ding -fstack-protector -Werror /usr/src/sys/amd64/amd64/identcpu.c cc1: warnings being treated as errors /usr/src/sys/amd64/amd64/identcpu.c: In function 'print_AMD_info': /usr/src/sys/amd64/amd64/identcpu.c:621: warning: implicit declaration of functi on 'CPUID_TO_FAMILY' /usr/src/sys/amd64/amd64/identcpu.c:621: warning: nested extern declaration of ' CPUID_TO_FAMILY' /usr/src/sys/amd64/amd64/identcpu.c:621: warning: implicit declaration of functi on 'CPUID_TO_MODEL' /usr/src/sys/amd64/amd64/identcpu.c:621: warning: nested extern declaration of ' CPUID_TO_MODEL' *** Error code 1 Stop in /usr/obj/usr/src/sys/KRNL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. smbserv01 src # This is on Core2 duo en quad core machines. My KRNL config file reads the following include GENERIC ident KRNL # pf options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ device pf device pflog device pfsync # Console color options options SC_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # number of history buffer lines my /etc/make.conf reads. CPUTYPE?=nocona KERNCONF=KRNL BATCH_DELETE_OLD_FILES= yes #BATCH=yes WITHOUT_X11=yes WITHOUT_GUI=yes # added by use.perl 2009-09-17 20:36:21 PERL_VERSION=5.10.1 Regards, Johan Hendriks From freebsd at jdc.parodius.com Fri Nov 6 15:43:51 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Fri Nov 6 15:43:57 2009 Subject: Buildworld on 8.0 RC2 fails. In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA57187@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCBA57187@w2003s01.double-l.local> Message-ID: <20091106154348.GA42813@icarus.home.lan> On Fri, Nov 06, 2009 at 04:26:57PM +0100, Johan Hendriks wrote: > I have 4 macines running FreeBSD 8.0RC2 , which where last updated on > 5/11/2009 > > I have csuped the src today, and on the buildworld cycle (make kernel ) > they all error out with the following error!! > > cc1: warnings being treated as errors > /usr/src/sys/amd64/amd64/identcpu.c: In function 'print_AMD_info': > /usr/src/sys/amd64/amd64/identcpu.c:621: warning: implicit declaration > of functi on > 'CPUID_TO_FAMILY' > /usr/src/sys/amd64/amd64/identcpu.c:621: warning: nested extern > declaration of ' > CPUID_TO_FAMILY' > /usr/src/sys/amd64/amd64/identcpu.c:621: warning: implicit declaration > of functi on > 'CPUID_TO_MODEL' > /usr/src/sys/amd64/amd64/identcpu.c:621: warning: nested extern > declaration of ' > CPUID_TO_MODEL' > *** Error code 1 This was fixed ~20 minutes ago. It may take time for the change to get committed to all of the cvsup servers. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/amd64/identcpu.c.diff?r1=1.174.2.2;r2=1.174.2.3;f=h The breakage occurred 5 hours ago. See commits to RELENG_8 tag, unless you're using RELENG_8_0: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/amd64/identcpu.c -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From tinderbox at freebsd.org Fri Nov 6 15:51:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 6 15:51:37 2009 Subject: [releng_8 tinderbox] failure on i386/pc98 Message-ID: <200911061521.nA6FL01f082612@freebsd-current.sentex.ca> TB --- 2009-11-06 14:09:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-06 14:09:41 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2009-11-06 14:09:41 - cleaning the object tree TB --- 2009-11-06 14:10:02 - cvsupping the source tree TB --- 2009-11-06 14:10:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2009-11-06 14:10:30 - building world TB --- 2009-11-06 14:10:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 14:10:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 14:10:30 - TARGET=pc98 TB --- 2009-11-06 14:10:30 - TARGET_ARCH=i386 TB --- 2009-11-06 14:10:30 - TZ=UTC TB --- 2009-11-06 14:10:30 - __MAKE_CONF=/dev/null TB --- 2009-11-06 14:10:30 - cd /src TB --- 2009-11-06 14:10:30 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 6 14:10:31 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 6 15:08:56 UTC 2009 TB --- 2009-11-06 15:08:56 - generating LINT kernel config TB --- 2009-11-06 15:08:56 - cd /src/sys/pc98/conf TB --- 2009-11-06 15:08:56 - /usr/bin/make -B LINT TB --- 2009-11-06 15:08:56 - building LINT kernel TB --- 2009-11-06 15:08:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 15:08:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 15:08:56 - TARGET=pc98 TB --- 2009-11-06 15:08:56 - TARGET_ARCH=i386 TB --- 2009-11-06 15:08:56 - TZ=UTC TB --- 2009-11-06 15:08:56 - __MAKE_CONF=/dev/null TB --- 2009-11-06 15:08:56 - cd /src TB --- 2009-11-06 15:08:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 6 15:08:56 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/i686_mem.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/i386/i386/identcpu.c cc1: warnings being treated as errors /src/sys/i386/i386/identcpu.c: In function 'print_AMD_info': /src/sys/i386/i386/identcpu.c:1317: warning: implicit declaration of function 'CPUID_TO_FAMILY' /src/sys/i386/i386/identcpu.c:1317: warning: nested extern declaration of 'CPUID_TO_FAMILY' /src/sys/i386/i386/identcpu.c:1317: warning: implicit declaration of function 'CPUID_TO_MODEL' /src/sys/i386/i386/identcpu.c:1317: warning: nested extern declaration of 'CPUID_TO_MODEL' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-06 15:21:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-06 15:21:00 - ERROR: failed to build lint kernel TB --- 2009-11-06 15:21:00 - 3184.58 user 656.99 system 4278.67 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From 000.fbsd at quip.cz Fri Nov 6 18:36:30 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Nov 6 18:36:43 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> Message-ID: <4AF46CA9.1040904@quip.cz> Ivan Voras wrote: > Miroslav Lachman wrote: >> Ivan Voras wrote: >>> Miroslav Lachman wrote: >> >> [..] >> >>>> I have more strange issue with Lighttpd in jail on top of ZFS. >>>> Lighttpd is serving static content (mp3 downloads thru flash player). >>>> Is runs fine for relatively small number of parallel clients with >>>> bandwidth about 30 Mbps, but after some number of clients is reached >>>> (about 50-60 parallel clients) the throughput drops down to 6 Mbps. >>>> >>>> I can server hundereds of clients on same HW using Lighttpd not in >>>> jail and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe >>>> more). >>>> >>>> I don't know if it is ZFS or Jail issue. >>> >>> Do you have actual disk IO or is the vast majority of your data served >>> from the caches? (actually - the same question to the OP) >> >> I had ZFS zpool as mirror of two SATA II drives (500GB) and in the >> peak iostat (or systat -vm or gstat) shows about 80 tps / 60% busy. >> >> In case of UFS, I am using gmirrored 1TB SATA II drives working nice >> with 160 or more tps. >> >> Both setups are using FreeBSD 7.x amd64 with GENERIC kernel, 4GB of RAM. >> >> As the ZFS + Lighttpd in jail was unreliable, I am no longer using it, >> but if you want some more info for debuging, I can set it up again. > > For what it's worth, I have just set up a little test on a production > machine with 3 500 GB SATA drives in RAIDZ, FreeBSD 7.2-RELEASE. The > total data set is some 2 GB in 5000 files but the machine has only 2 GB > RAM total so there is some disk IO - about 40 IOPS per drive. I'm also > using Apache-worker, not lighty, and siege to benchmark with 10 > concurrent users. > > In this setup, the machine has no problems saturating a 100 Mbit/s link > - it's not on a LAN but the latency is close enough and I get ~~ 11 MB/s. I tried it again to get some system statistics for you, so here it comes. I do not understand why there are 10MB/s read from disks when network traffic dropped to around 1MB/s (8Mbps) root@cage ~/# iostat -w 20 tty ad4 ad6 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 14 41.66 53 2.17 41.82 53 2.18 0 0 2 0 97 0 18 50.92 96 4.77 54.82 114 6.12 0 0 3 1 96 0 6 53.52 101 5.29 54.98 108 5.81 1 0 4 1 94 0 6 54.82 98 5.26 55.89 108 5.89 0 0 3 1 96 root@cage ~/# ifstat -i bge1 10 bge1 KB/s in KB/s out 33.32 1174.34 34.35 1181.33 33.14 1172.27 31.64 1118.60 root@cage ~/# zpool iostat 10 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- tank 382G 62.5G 73 31 3.30M 148K tank 382G 62.5G 150 38 11.2M 138K tank 382G 62.5G 148 33 11.3M 99.6K tank 382G 62.5G 148 29 10.9M 93.2K tank 382G 62.5G 137 25 10.4M 75.4K tank 382G 62.5G 149 32 11.3M 122K root@cage ~/# ~/bin/zfs_get_kernel_mem.sh TEXT=13245157, 12.6316 MB DATA=267506688, 255.114 MB TOTAL=280751845, 267.746 MB root@cage ~/# ~/bin/arcstat.pl 10 Time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c 15:34:38 705M 46M 6 46M 6 0 0 29M 18 137061376 134217728 15:34:48 1K 148 11 148 11 0 0 57 96 137495552 134217728 15:34:58 1K 151 11 151 11 0 0 59 96 136692736 134217728 15:35:08 1K 140 10 140 10 0 0 45 76 165005824 134217728 15:35:18 1K 150 9 150 9 0 0 54 91 141642240 134217728 root@cage ~/# ~/bin/arc_summary.pl System Memory: Physical RAM: 4083 MB Free Memory : 0 MB ARC Size: Current Size: 133 MB (arcsize) Target Size (Adaptive): 128 MB (c) Min Size (Hard Limit): 16 MB (zfs_arc_min) Max Size (Hard Limit): 128 MB (zfs_arc_max) ARC Size Breakdown: Most Recently Used Cache Size: 97% 125 MB (p) Most Frequently Used Cache Size: 2% 2 MB (c-p) ARC Efficency: Cache Access Total: 7052224705 Cache Hit Ratio: 93% 6582803808 [Defined State for buffer] Cache Miss Ratio: 6% 469420897 [Undefined State for Buffer] REAL Hit Ratio: 93% 6582803808 [MRU/MFU Hits Only] Data Demand Efficiency: 96% Data Prefetch Efficiency: DISABLED (zfs_prefetch_disable) CACHE HITS BY CACHE LIST: Anon: --% Counter Rolled. Most Recently Used: 13% 869219380 (mru) [ Return Customer ] Most Frequently Used: 86% 5713584428 (mfu) [ Frequent Customer ] Most Recently Used Ghost: 0% 25025402 (mru_ghost) [ Return Customer Evicted, Now Back ] Most Frequently Used Ghost: 1% 103104325 (mfu_ghost) [ Frequent Customer Evicted, Now Back ] CACHE HITS BY DATA TYPE: Demand Data: 80% 5331503088 Prefetch Data: 0% 0 Demand Metadata: 19% 1251300720 Prefetch Metadata: 0% 0 CACHE MISSES BY DATA TYPE: Demand Data: 38% 179172125 Prefetch Data: 0% 0 Demand Metadata: 61% 290248772 Prefetch Metadata: 0% 0 --------------------------------------------- /boot/loader.conf: ## eLOM support hw.bge.allow_asf="1" ## gmirror RAID1 geom_mirror_load="YES" ## ZFS tuning vm.kmem_size="1280M" vm.kmem_size_max="1280M" kern.maxvnodes="400000" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="128M" The network traffic is normally around 30Mbps, but when number of parallel downloads reaches some level, traffic drops to 6-8Mbps and number of parallel clients goes up even more. I can provide network and disk IO graphs if you are interested. Miroslav Lachman From serenity at exscape.org Fri Nov 6 18:45:51 2009 From: serenity at exscape.org (Thomas Backman) Date: Fri Nov 6 18:45:59 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <4AF46CA9.1040904@quip.cz> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> Message-ID: On Nov 6, 2009, at 7:36 PM, Miroslav Lachman wrote: > Ivan Voras wrote: >> Miroslav Lachman wrote: >>> Ivan Voras wrote: >>>> Miroslav Lachman wrote: >>> >>> [..] >>> >>>>> I have more strange issue with Lighttpd in jail on top of ZFS. >>>>> Lighttpd is serving static content (mp3 downloads thru flash >>>>> player). >>>>> Is runs fine for relatively small number of parallel clients with >>>>> bandwidth about 30 Mbps, but after some number of clients is >>>>> reached >>>>> (about 50-60 parallel clients) the throughput drops down to 6 >>>>> Mbps. >>>>> >>>>> I can server hundereds of clients on same HW using Lighttpd not in >>>>> jail and UFS2 with gjournal instead of ZFS reaching 100 Mbps >>>>> (maybe >>>>> more). >>>>> >>>>> I don't know if it is ZFS or Jail issue. >>>> >>>> Do you have actual disk IO or is the vast majority of your data >>>> served >>>> from the caches? (actually - the same question to the OP) >>> >>> I had ZFS zpool as mirror of two SATA II drives (500GB) and in the >>> peak iostat (or systat -vm or gstat) shows about 80 tps / 60% busy. >>> >>> In case of UFS, I am using gmirrored 1TB SATA II drives working nice >>> with 160 or more tps. >>> >>> Both setups are using FreeBSD 7.x amd64 with GENERIC kernel, 4GB >>> of RAM. >>> >>> As the ZFS + Lighttpd in jail was unreliable, I am no longer using >>> it, >>> but if you want some more info for debuging, I can set it up again. >> >> For what it's worth, I have just set up a little test on a production >> machine with 3 500 GB SATA drives in RAIDZ, FreeBSD 7.2-RELEASE. The >> total data set is some 2 GB in 5000 files but the machine has only >> 2 GB >> RAM total so there is some disk IO - about 40 IOPS per drive. I'm >> also >> using Apache-worker, not lighty, and siege to benchmark with 10 >> concurrent users. >> >> In this setup, the machine has no problems saturating a 100 Mbit/s >> link >> - it's not on a LAN but the latency is close enough and I get ~~ 11 >> MB/s. > > [...] > /boot/loader.conf: > > ## eLOM support > hw.bge.allow_asf="1" > ## gmirror RAID1 > geom_mirror_load="YES" > ## ZFS tuning > vm.kmem_size="1280M" > vm.kmem_size_max="1280M" > kern.maxvnodes="400000" > vfs.zfs.prefetch_disable="1" > vfs.zfs.arc_min="16M" > vfs.zfs.arc_max="128M" I won't pretend to know much about this area, but your ZFS values here are very low. May I assume that they are remnants of the times when the ARC grew insanely large and caused a kernel panic? You're effectively forcing ZFS to not use more than 128MB cache, which doesn't sound like a great idea if you've got 2+ GB of RAM. I've had no trouble without any tuning whatsoever on 2GB for a long time now. The kmem lines can probably be omitted if you're on amd64, too (the default value for kmem_size_max is about 307GB on my machine). Regards, Thomas From ivoras at freebsd.org Fri Nov 6 19:01:38 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Nov 6 19:01:45 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <4AF46CA9.1040904@quip.cz> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> Message-ID: <9bbcef730911061101h5356d2acob2ac8791afe112@mail.gmail.com> 2009/11/6 Miroslav Lachman <000.fbsd@quip.cz>: > I do not understand why there are 10MB/s read from disks when network > traffic dropped to around 1MB/s (8Mbps) > > root@cage ~/# iostat -w 20 > ? ? ?tty ? ? ? ? ? ? ad4 ? ? ? ? ? ? ?ad6 ? ? ? ? ? ? cpu > ?tin tout ?KB/t tps ?MB/s ? KB/t tps ?MB/s ?us ni sy in id > ? 0 ? 14 41.66 ?53 ?2.17 ?41.82 ?53 ?2.18 ? 0 ?0 ?2 ?0 97 > ? 0 ? 18 50.92 ?96 ?4.77 ?54.82 114 ?6.12 ? 0 ?0 ?3 ?1 96 > ? 0 ? ?6 53.52 101 ?5.29 ?54.98 108 ?5.81 ? 1 ?0 ?4 ?1 94 > ? 0 ? ?6 54.82 ?98 ?5.26 ?55.89 108 ?5.89 ? 0 ?0 ?3 ?1 96 Yes, this could limit your IO if the requests are random enough. Unfortunately I don't know how would you track down what is really going on. Maybe some tracing with DTrace? I'd tell you to use "top -m io" to see if there is a process responsible, but apparently these statistics are not updated for ZFS, which in itself may be a bug (which is why I'm crossposting to freebsd-fs). From mloftis at wgops.com Fri Nov 6 20:08:28 2009 From: mloftis at wgops.com (Michael Loftis) Date: Fri Nov 6 20:08:46 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <4AEEBD4B.1050407@quip.cz> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> Message-ID: --On Monday, November 02, 2009 12:06 PM +0100 Miroslav Lachman <000.fbsd@quip.cz> wrote: > I have more strange issue with Lighttpd in jail on top of ZFS. Lighttpd > is serving static content (mp3 downloads thru flash player). Is runs fine > for relatively small number of parallel clients with bandwidth about 30 > Mbps, but after some number of clients is reached (about 50-60 parallel > clients) the throughput drops down to 6 Mbps. > > I can server hundereds of clients on same HW using Lighttpd not in jail > and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe more). > > I don't know if it is ZFS or Jail issue. Check iostat 5 or zpool iostat 5 -- I bet you're disk thrashing when you start to slow down. From mloftis at wgops.com Fri Nov 6 20:08:28 2009 From: mloftis at wgops.com (Michael Loftis) Date: Fri Nov 6 20:08:47 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> Message-ID: <8378FC0601DCAA4F0E88C577@[192.168.1.44]> --On Monday, November 02, 2009 10:52 AM +0100 Ivan Voras wrote: > AFAIK, ZFS is incompatible (currently) with some advanced VM operations > (like mmap, and I think sendfile relies on the same mechanism as mmap), > so that could be a cause of the slowdown. Though I'm surprised you can > only get 200 MBit/s - that's 25 MB/s and I think that even with multiple > memcpy-ing data around the kernel you should be able to get hundreds of > MB/s on newer hardware (which normally really can achieve tens of > gigabytes/s of sustained memory access). > > What else can you observe from your system? Do you have exceedingly high > sys times and load numbers? I'm also interested in what does 10 seconds > of running 'vmstat 1' looks like on your system. Is it a bare machine or > a virtual machine? Real hardware, dual quad core opteron with 64GB memory, a 3Ware 9650SE for disks. The rest of the machine is not doing much if anything when the issue happens. I've had to remove ZFS from all of the media streaming servers. I ca probably get one up for testing again over the next few weeks. I've some more hardware coming in. From mloftis at wgops.com Fri Nov 6 20:08:28 2009 From: mloftis at wgops.com (Michael Loftis) Date: Fri Nov 6 20:08:48 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> Message-ID: <5275583A0E66749DA096A22F@[192.168.1.44]> --On Monday, November 02, 2009 12:55 PM +0100 Ivan Voras wrote: > Do you have actual disk IO or is the vast majority of your data served > from the caches? (actually - the same question to the OP) That's the problem 64GB of RAM and ZFS doesn't seem to use any cache. It also seems to not be realizing when multiple reads are on the same block (same issue sorta) and dispatches the same I/O request. From rmacklem at uoguelph.ca Fri Nov 6 20:32:40 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri Nov 6 20:32:47 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: <20091102100958.GY841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> <20091029135239.GX841@twoquid.cs.ru.nl> <20091102100958.GY841@twoquid.cs.ru.nl> Message-ID: On Mon, 2 Nov 2009, Olaf Seibert wrote: >> Although I think the patch does avoid sending the request on the >> partially closed connection, it doesn't fix the "real problem", >> so I don't know if it is worth testing? > > Well, I tested it anyway, just in case. It seems to work fine for me, so > far. > > I don't see your extra RSTs either. Maybe that is because in my case the > client used a different port number for the new connection. (Usually, > this is controlled by the TCP option SO_REUSEADDR from ). > It seems that the pesky RSTs I was seeing were generated by the net chip in the machine I was using (Intel 82801BA/CAM - fxp driver) when TSO was enabled for it. sysctl net.inet.tcp.tso=0 got rid of the problem and, with the patch you already tested, thinks are testing well here. If anyone is still having NFS over TCP reconnect problems after applying the patch, please try the above and see if it helps. Thanks, rick From ben at wanderview.com Fri Nov 6 20:51:50 2009 From: ben at wanderview.com (Ben Kelly) Date: Fri Nov 6 20:51:57 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <5275583A0E66749DA096A22F@[192.168.1.44]> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <5275583A0E66749DA096A22F@[192.168.1.44]> Message-ID: <696A0DF1-020B-48CB-BF38-6605EAD5BF1E@wanderview.com> On Nov 6, 2009, at 2:53 PM, Michael Loftis wrote: > --On Monday, November 02, 2009 12:55 PM +0100 Ivan Voras > wrote: > >> Do you have actual disk IO or is the vast majority of your data >> served >> from the caches? (actually - the same question to the OP) > > That's the problem 64GB of RAM and ZFS doesn't seem to use any > cache. It also seems to not be realizing when multiple reads are on > the same block (same issue sorta) and dispatches the same I/O request. Have you tried adjusting vfs.zfs.arc_meta_limit? I've noticed the default value for this is set poorly when the overall ARC size is small. This happens because various structure's not actually allocated from the ARC like dnodes and dbufs are included in the metadata usage stats. When the ARC is large this is somewhat negligible, but for small ARCs it overwhelms the calculated default metadata limit and you end up not caching any real file system metadata. You could try increasing the metadata limit or even better increase your maximum ARC size to something over 1GB. (I seem to remember your ARC size is 128M from earlier in the thread). Hope that helps. - Ben From mloftis at wgops.com Fri Nov 6 21:11:53 2009 From: mloftis at wgops.com (Michael Loftis) Date: Fri Nov 6 21:12:00 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <696A0DF1-020B-48CB-BF38-6605EAD5BF1E@wanderview.com> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <5275583A0E66749DA096A22F@[192.168.1.44]> <696A0DF1-020B-48CB-BF38-6605EAD5BF1E@wanderview.com> Message-ID: <94A540AC0E2A75B7CA3ED7F7@[192.168.1.44]> --On Friday, November 06, 2009 3:31 PM -0500 Ben Kelly wrote: > Have you tried adjusting vfs.zfs.arc_meta_limit? I've noticed the > default value for this is set poorly when the overall ARC size is small. > This happens because various structure's not actually allocated from the > ARC like dnodes and dbufs are included in the metadata usage stats. When > the ARC is large this is somewhat negligible, but for small ARCs it > overwhelms the calculated default metadata limit and you end up not > caching any real file system metadata. > > You could try increasing the metadata limit or even better increase your > maximum ARC size to something over 1GB. (I seem to remember your ARC > size is 128M from earlier in the thread). Nope, that was someone else, not setting any ARC limits (or any ZFS settings at all actually). > > Hope that helps. > > - Ben > From 000.fbsd at quip.cz Fri Nov 6 22:27:33 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Nov 6 22:27:40 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> Message-ID: <4AF4A2D1.7090604@quip.cz> Michael Loftis wrote: >> I have more strange issue with Lighttpd in jail on top of ZFS. Lighttpd >> is serving static content (mp3 downloads thru flash player). Is runs fine >> for relatively small number of parallel clients with bandwidth about 30 >> Mbps, but after some number of clients is reached (about 50-60 parallel >> clients) the throughput drops down to 6 Mbps. >> >> I can server hundereds of clients on same HW using Lighttpd not in jail >> and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe more). >> >> I don't know if it is ZFS or Jail issue. > > > Check iostat 5 or zpool iostat 5 -- I bet you're disk thrashing when you > start to slow down. iostat and zpool was posted in another message. gstat or systat -vm is showing about 60% busy disk and even if there is high IO on the disks, lighttpd serving the same content from gmirrored UFS2 with gjournal and not in jail is serving three times more clients and bandwidth without this drop down behavior. Both machines are Sun Fire X2100 M2 with SATA disks. Miroslav Lachman From 000.fbsd at quip.cz Fri Nov 6 22:41:21 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri Nov 6 22:41:29 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> Message-ID: <4AF4A608.4020706@quip.cz> Thomas Backman wrote: > On Nov 6, 2009, at 7:36 PM, Miroslav Lachman wrote: > >> Ivan Voras wrote: >>> Miroslav Lachman wrote: >>>> Ivan Voras wrote: >>>>> Miroslav Lachman wrote: >>>> >>>> [..] >>>> >>>>>> I have more strange issue with Lighttpd in jail on top of ZFS. >>>>>> Lighttpd is serving static content (mp3 downloads thru flash player). >>>>>> Is runs fine for relatively small number of parallel clients with >>>>>> bandwidth about 30 Mbps, but after some number of clients is reached >>>>>> (about 50-60 parallel clients) the throughput drops down to 6 Mbps. >>>>>> >>>>>> I can server hundereds of clients on same HW using Lighttpd not in >>>>>> jail and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe >>>>>> more). >>>>>> >>>>>> I don't know if it is ZFS or Jail issue. >>>>> >>>>> Do you have actual disk IO or is the vast majority of your data served >>>>> from the caches? (actually - the same question to the OP) >>>> >>>> I had ZFS zpool as mirror of two SATA II drives (500GB) and in the >>>> peak iostat (or systat -vm or gstat) shows about 80 tps / 60% busy. >>>> >>>> In case of UFS, I am using gmirrored 1TB SATA II drives working nice >>>> with 160 or more tps. >>>> >>>> Both setups are using FreeBSD 7.x amd64 with GENERIC kernel, 4GB of >>>> RAM. >>>> >>>> As the ZFS + Lighttpd in jail was unreliable, I am no longer using it, >>>> but if you want some more info for debuging, I can set it up again. >>> >>> For what it's worth, I have just set up a little test on a production >>> machine with 3 500 GB SATA drives in RAIDZ, FreeBSD 7.2-RELEASE. The >>> total data set is some 2 GB in 5000 files but the machine has only 2 GB >>> RAM total so there is some disk IO - about 40 IOPS per drive. I'm also >>> using Apache-worker, not lighty, and siege to benchmark with 10 >>> concurrent users. >>> >>> In this setup, the machine has no problems saturating a 100 Mbit/s link >>> - it's not on a LAN but the latency is close enough and I get ~~ 11 >>> MB/s. >> >> [...] >> /boot/loader.conf: >> >> ## eLOM support >> hw.bge.allow_asf="1" >> ## gmirror RAID1 >> geom_mirror_load="YES" >> ## ZFS tuning >> vm.kmem_size="1280M" >> vm.kmem_size_max="1280M" >> kern.maxvnodes="400000" >> vfs.zfs.prefetch_disable="1" >> vfs.zfs.arc_min="16M" >> vfs.zfs.arc_max="128M" > I won't pretend to know much about this area, but your ZFS values here > are very low. May I assume that they are remnants of the times when the > ARC grew insanely large and caused a kernel panic? > You're effectively forcing ZFS to not use more than 128MB cache, which > doesn't sound like a great idea if you've got 2+ GB of RAM. I've had no > trouble without any tuning whatsoever on 2GB for a long time now. The > kmem lines can probably be omitted if you're on amd64, too (the default > value for kmem_size_max is about 307GB on my machine). Yes, loader values are one year old when I installed this machine. But I think auto tuning was commited after 7.2-RELEASE by Kip Macy, so some of them are still needed or am I wrong? (this is 7.2-RELEASE). I can grow arc_max but as this machine is running about 6 jails (not CPU or disk IO consuming), I still need some memory for processes, not just for filesystem. From zkolic at sbb.rs Sat Nov 7 06:14:18 2009 From: zkolic at sbb.rs (Zoran Kolic) Date: Sat Nov 7 06:14:26 2009 Subject: hardware for 8.0 Message-ID: <20091107060215.GA1180@faust.net> Howdy! I have a plan to build new box at time, when 8.0 release will come up. Would be fine to have opinions on the list, what to buy, to fully implement it to desktop node. My idea is to get some 4 core phenom II cpu, with not expensive mobo. Another dilema is the graphical card. At this moment I have agp version of nvidia 6200, fanless, that manages just fine. Something similar on pci-e, not fancy, 2D. I'm really puzzled should it be amd or nvidia with newest am3 mobos. And the last, ethernet port on the mobo was the problem on my present k8n. After introduction of nfe driver all is fine. If recommended card has not working port, what to buy separately? As you already guessed, I don't want to spend a little fortune for this node. Decent, but not expensive, that's it. Best regards Zoran From freebsd at jdc.parodius.com Sat Nov 7 07:31:54 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Sat Nov 7 07:32:33 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <4AF4A608.4020706@quip.cz> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> <4AF4A608.4020706@quip.cz> Message-ID: <20091107073151.GA60756@icarus.home.lan> On Fri, Nov 06, 2009 at 11:41:12PM +0100, Miroslav Lachman wrote: > Thomas Backman wrote: > >On Nov 6, 2009, at 7:36 PM, Miroslav Lachman wrote: > > > >>Ivan Voras wrote: > >>>Miroslav Lachman wrote: > >>>>Ivan Voras wrote: > >>>>>Miroslav Lachman wrote: > >>>> > >>>>[..] > >>>> > >>>>>>I have more strange issue with Lighttpd in jail on top of ZFS. > >>>>>>Lighttpd is serving static content (mp3 downloads thru flash player). > >>>>>>Is runs fine for relatively small number of parallel clients with > >>>>>>bandwidth about 30 Mbps, but after some number of clients is reached > >>>>>>(about 50-60 parallel clients) the throughput drops down to 6 Mbps. > >>>>>> > >>>>>>I can server hundereds of clients on same HW using Lighttpd not in > >>>>>>jail and UFS2 with gjournal instead of ZFS reaching 100 Mbps (maybe > >>>>>>more). > >>>>>> > >>>>>>I don't know if it is ZFS or Jail issue. > >>>>> > >>>>>Do you have actual disk IO or is the vast majority of your data served > >>>>>from the caches? (actually - the same question to the OP) > >>>> > >>>>I had ZFS zpool as mirror of two SATA II drives (500GB) and in the > >>>>peak iostat (or systat -vm or gstat) shows about 80 tps / 60% busy. > >>>> > >>>>In case of UFS, I am using gmirrored 1TB SATA II drives working nice > >>>>with 160 or more tps. > >>>> > >>>>Both setups are using FreeBSD 7.x amd64 with GENERIC kernel, 4GB of > >>>>RAM. > >>>> > >>>>As the ZFS + Lighttpd in jail was unreliable, I am no longer using it, > >>>>but if you want some more info for debuging, I can set it up again. > >>> > >>>For what it's worth, I have just set up a little test on a production > >>>machine with 3 500 GB SATA drives in RAIDZ, FreeBSD 7.2-RELEASE. The > >>>total data set is some 2 GB in 5000 files but the machine has only 2 GB > >>>RAM total so there is some disk IO - about 40 IOPS per drive. I'm also > >>>using Apache-worker, not lighty, and siege to benchmark with 10 > >>>concurrent users. > >>> > >>>In this setup, the machine has no problems saturating a 100 Mbit/s link > >>>- it's not on a LAN but the latency is close enough and I get ~~ 11 > >>>MB/s. > >> > >>[...] > >>/boot/loader.conf: > >> > >>## eLOM support > >>hw.bge.allow_asf="1" > >>## gmirror RAID1 > >>geom_mirror_load="YES" > >>## ZFS tuning > >>vm.kmem_size="1280M" > >>vm.kmem_size_max="1280M" > >>kern.maxvnodes="400000" > >>vfs.zfs.prefetch_disable="1" > >>vfs.zfs.arc_min="16M" > >>vfs.zfs.arc_max="128M" > > >I won't pretend to know much about this area, but your ZFS values here > >are very low. May I assume that they are remnants of the times when the > >ARC grew insanely large and caused a kernel panic? > >You're effectively forcing ZFS to not use more than 128MB cache, which > >doesn't sound like a great idea if you've got 2+ GB of RAM. I've had no > >trouble without any tuning whatsoever on 2GB for a long time now. The > >kmem lines can probably be omitted if you're on amd64, too (the default > >value for kmem_size_max is about 307GB on my machine). > > Yes, loader values are one year old when I installed this machine. > But I think auto tuning was commited after 7.2-RELEASE by Kip Macy, > so some of them are still needed or am I wrong? (this is > 7.2-RELEASE). ... We don't know, because none of the individuals who are maintaining ZFS at this point in time have actually responded to this question. http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html The community really needs an official answer to this question, and one from those familiar with the code. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ivoras at freebsd.org Sat Nov 7 10:45:26 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 7 10:45:56 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <20091107073151.GA60756@icarus.home.lan> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> <4AF4A608.4020706@quip.cz> <20091107073151.GA60756@icarus.home.lan> Message-ID: <9bbcef730911070245r2cc11136w5ea16f903e91ba3e@mail.gmail.com> 2009/11/7 Jeremy Chadwick : >> Yes, loader values are one year old when I installed this machine. >> But I think auto tuning was commited after 7.2-RELEASE by Kip Macy, >> so some of them are still needed or am I wrong? (this is >> 7.2-RELEASE). ... > > We don't know, because none of the individuals who are maintaining ZFS > at this point in time have actually responded to this question. > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html Only as a data point and not suggesting anything official: I have managed to panic 8-STABLE with ZFS kmem exhaustion, so... *shrug* I'm still scared of using it. From 000.fbsd at quip.cz Sat Nov 7 20:18:31 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sat Nov 7 20:18:44 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <9bbcef730911061101h5356d2acob2ac8791afe112@mail.gmail.com> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> <9bbcef730911061101h5356d2acob2ac8791afe112@mail.gmail.com> Message-ID: <4AF5D611.7060408@quip.cz> Ivan Voras wrote: > 2009/11/6 Miroslav Lachman<000.fbsd@quip.cz>: > >> I do not understand why there are 10MB/s read from disks when network >> traffic dropped to around 1MB/s (8Mbps) >> >> root@cage ~/# iostat -w 20 >> tty ad4 ad6 cpu >> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >> 0 14 41.66 53 2.17 41.82 53 2.18 0 0 2 0 97 >> 0 18 50.92 96 4.77 54.82 114 6.12 0 0 3 1 96 >> 0 6 53.52 101 5.29 54.98 108 5.81 1 0 4 1 94 >> 0 6 54.82 98 5.26 55.89 108 5.89 0 0 3 1 96 > > Yes, this could limit your IO if the requests are random enough. > Unfortunately I don't know how would you track down what is really > going on. Maybe some tracing with DTrace? > > I'd tell you to use "top -m io" to see if there is a process > responsible, but apparently these statistics are not updated for ZFS, > which in itself may be a bug (which is why I'm crossposting to > freebsd-fs). DTrace is totally out of my skills ;( There is otput of top -m io sorted by VCSW displaying JID. last pid: 17724; load averages: 0.01, 0.07, 0.08 up 74+20:49:49 21:03:40 195 processes: 1 running, 193 sleeping, 1 zombie CPU: 0.0% user, 0.0% nice, 3.6% system, 0.4% interrupt, 96.1% idle Mem: 462M Active, 2385M Inact, 977M Wired, 21M Cache, 399M Buf, 100M Free Swap: 6144M Total, 2024K Used, 6142M Free PID JID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 17681 8 www 657 64 0 0 0 0 0.00% lighttpd 17683 8 www 379 41 0 0 0 0 0.00% lighttpd 17680 8 www 136 5 0 0 0 0 0.00% lighttpd 17682 8 www 85 0 0 0 0 0 0.00% lighttpd 4689 1 90 10 0 0 0 0 0 0.00% fb_inet_server 3403 1 90 10 0 0 0 0 0 0.00% fb_inet_server 2632 1 90 10 0 0 0 0 0 0.00% fb_inet_server All four top consumers is Lighttpd workers. And as you noted, read, write, fault, total and percent are not updated on machine with ZFS, so I can't compare it with UFS2 based machine. Is this bug in top fixed in 8.x? Will you file a PR? (you know more about FS related things than me :]) Miroslav Lachman From ivoras at freebsd.org Sat Nov 7 20:42:48 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 7 20:43:00 2009 Subject: Performance issues with 8.0 ZFS and sendfile/lighttpd In-Reply-To: <4AF5D611.7060408@quip.cz> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> <9bbcef730911061101h5356d2acob2ac8791afe112@mail.gmail.com> <4AF5D611.7060408@quip.cz> Message-ID: <9bbcef730911071242m5ad91720xcccb7586c6848ffd@mail.gmail.com> 2009/11/7 Miroslav Lachman <000.fbsd@quip.cz>: > > And as you noted, read, write, fault, total and percent are not updated on > machine with ZFS, so I can't compare it with UFS2 based machine. > Is this bug in top fixed in 8.x? Will you file a PR? (you know more about FS > related things than me :]) Not much... it depends on from where the stats are collected - there is a fair bit of file system infrastructure that ZFS bypasses and if these stats come from it, they cannot be collected. The stat is apparently updated around sys/kern/vfs_cluster.c: 233 . I'm not very familiar with this layer but since it uses struct buf and the ZFS doesn't use bufcache, this is probably one of the things that is bypassed, though it would be nice if it weren't since this code also defines and uses the vfs.write_behind and vfs.read_max sysctls. Also, since ZFS uses its own threads for IO and the stats are for curthread, it looks like it would maybe need careful work to actually assign the IO stats to the correct thread; otherwise it may be sufficient to add it to vdev_disk.c in vdev_disk_physio(). I don't really know this code and this is mostly mechanical analisys - it might be wrong. At least I'd like to read someone's comment about what is curthread in this code path. From geoff at apro.com.au Sun Nov 8 14:09:11 2009 From: geoff at apro.com.au (Geoff Roberts) Date: Sun Nov 8 14:09:19 2009 Subject: Problems moving hostapd AP config from 6.4 to 8.0RC2 Message-ID: <200911090053.47239.geoff@apro.com.au> Hi, I had a working hostapd wireless access point configuration in FreeBSD 6.4. The access point is being used by Windows XP workstations. I was using WPA-EAP with freeradius authentication very successfully on the 6.4 backend. After making the changes for a new 8.0 RC2 (see below) system the XP clients cannot seem to authenticate. The radius server does not even get contacted by hostapd. I can get WEP and WPA-PSK to work OK - just WPA-EAP fails to work in 8.0RC2. I also have a dhcp server running to hand out dynamic addresses. Please let me know if you have any suggestions as to how to debug the issue further or where I may be going wrong. ==== hostapd.log is showing the following: -> Startup Nov 8 23:06:26 freebsd hostapd: wlan0: IEEE 802.11 Fetching hardware channel/rate support not supported. Nov 8 23:06:26 freebsd hostapd: wlan0: RADIUS Authentication server xxx.xxx.xxx.xxx:1812 -> When XP client tries to connect to AP Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 1 notification Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: start authentication Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: start authentication Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: unauthorizing port Nov 8 23:08:46 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: received EAPOL-Start from STA Nov 8 23:08:46 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 5 notification ----> Hangs here for a while Nov 9 00:32:23 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deassociated Nov 9 00:32:23 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 2 notification ===== tcpdump -i wlan0: 00:33:45.570161 xx:xx:xx:xx:xx:xx (oui Unknown) > Broadcast Null Supervisory, Receiver not Ready, rcv seq 64, Flags [Poll], length 6 00:33:45.570174 xx:xx:xx:xx:xx:xx (oui Unknown) > Broadcast Null Supervisory, Receiver not Ready, rcv seq 64, Flags [Poll], length 6 00:33:48.523053 EAPOL start (1) v1, len 0 === dmesg: ath0: mem 0xf9000000-0xf900ffff irq 16 at device 8.0 on pci1 ath0: [ITHREAD] ath0: AR5212 mac 5.6 RF5111 phy 4.1 === rc.conf I have converted the 6.4 files from: ifconfig_ath0="inet xxx.xxx.xxx.1 netmask xxx.xxx.xxx.192 mode 11g mediaopt hostap" to the newer 8.0 format: wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap mode 11g country Australia" ifconfig_wlan0="inet xxx.xxx.xxx.1 netmask xxx.xxx.xxx.192" ifconfig_wlan0_alias0="inet xxx.xxx.xxx.65 netmask xxx.xxx.xxx.192" ifconfig_wlan0_alias1="inet xxx.xxx.xxx.129 netmask xxx.xxx.xxx.192" ifconfig_wlan0_alias2="inet xxx.xxx.xxx.193 netmask xxx.xxx.xxx.192" NOTE, I found the order of items in create_args_wlan0 important. ==== I also adjusted the 6.4 hostapd.conf. Changes in 8.0RC2 are shown with -> ===== interface=ath0 -> wlan0 driver=bsd -> country_code=Australia logger_syslog=-1 logger_syslog_level=0 logger_stdout=-1 logger_stdout_level=0 debug=4 dump_file=/tmp/hostapd.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=netname macaddr_acl=0 ieee8021x=1 own_ip_addr=127.0.0.1 auth_server_addr=xxx.xxx.xxx.xxx auth_server_port=1812 auth_server_shared_secret=secretpw wpa=1 wpa_key_mgmt=WPA-EAP wpa_pairwise=CCMP TKIP === Extra debugging output from wlandebug: Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv probe req Nov 9 00:44:07 freebsd kernel: wlan0: send probe resp on channel 1 to xx:xx:xx:xx:xx:xx Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv probe req Nov 9 00:44:07 freebsd kernel: wlan0: send probe resp on channel 1 to xx:xx:xx:xx:xx:xx Nov 9 00:44:07 freebsd kernel: wlan0: received auth from xx:xx:xx:xx:xx:xx rssi 24 Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv auth frame with algorithm 0 seq 1 Nov 9 00:44:07 freebsd kernel: [xx:xx:xx:xx:xx:xx] send auth on channel 1 Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station authenticated (open) Nov 9 00:44:07 freebsd kernel: wlan0: received assoc_req from xx:xx:xx:xx:xx:xx rssi 24 Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] WPA ie: mc 1/0 uc 3/0 key 1 caps 0x0 Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station associated at aid 1: short preamble, short slot time, QoS Nov 9 00:44:07 freebsd kernel: [xx:xx:xx:xx:xx:xx] send assoc_resp on channel 1 Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station unauthorize via MLME === Kind regards, Geoff From sam at freebsd.org Sun Nov 8 16:48:46 2009 From: sam at freebsd.org (Sam Leffler) Date: Sun Nov 8 16:48:53 2009 Subject: Problems moving hostapd AP config from 6.4 to 8.0RC2 In-Reply-To: <200911090053.47239.geoff@apro.com.au> References: <200911090053.47239.geoff@apro.com.au> Message-ID: <4AF6F669.6050403@freebsd.org> Geoff Roberts wrote: > Hi, > > I had a working hostapd wireless access point configuration in FreeBSD 6.4. > The access point is being used by Windows XP workstations. > > I was using WPA-EAP with freeradius authentication very successfully on the > 6.4 backend. > > After making the changes for a new 8.0 RC2 (see below) system the XP clients > cannot seem to authenticate. The radius server does not even get contacted by > hostapd. > > I can get WEP and WPA-PSK to work OK - just WPA-EAP fails to work in 8.0RC2. > > I also have a dhcp server running to hand out dynamic addresses. > > Please let me know if you have any suggestions as to how to debug the issue > further or where I may be going wrong. > > ==== > > hostapd.log is showing the following: > > -> Startup > Nov 8 23:06:26 freebsd hostapd: wlan0: IEEE 802.11 Fetching hardware > channel/rate support not supported. > Nov 8 23:06:26 freebsd hostapd: wlan0: RADIUS Authentication server > xxx.xxx.xxx.xxx:1812 > -> When XP client tries to connect to AP > Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: > associated > Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 1 > notification > Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: > start authentication > Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: start > authentication > Nov 8 23:08:43 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: > unauthorizing port > Nov 8 23:08:46 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: > received EAPOL-Start from STA > Nov 8 23:08:46 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 5 > notification > ----> Hangs here for a while > Nov 9 00:32:23 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: > deassociated > Nov 9 00:32:23 freebsd hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: event 2 > notification Doesn't look like you're getting any debugging from hostapd so we cannot see why it's giving up and dropping the station. > > ===== > > tcpdump -i wlan0: > > 00:33:45.570161 xx:xx:xx:xx:xx:xx (oui Unknown) > Broadcast Null Supervisory, > Receiver not Ready, rcv seq 64, Flags [Poll], length 6 > 00:33:45.570174 xx:xx:xx:xx:xx:xx (oui Unknown) > Broadcast Null Supervisory, > Receiver not Ready, rcv seq 64, Flags [Poll], length 6 > 00:33:48.523053 EAPOL start (1) v1, len 0 > > > > === > dmesg: > ath0: mem 0xf9000000-0xf900ffff irq 16 at device 8.0 on pci1 > ath0: [ITHREAD] > ath0: AR5212 mac 5.6 RF5111 phy 4.1 > === > > rc.conf > > I have converted the 6.4 files from: > > ifconfig_ath0="inet xxx.xxx.xxx.1 netmask xxx.xxx.xxx.192 mode 11g mediaopt > hostap" > > to the newer 8.0 format: > > wlans_ath0="wlan0" > create_args_wlan0="wlanmode hostap mode 11g country Australia" > ifconfig_wlan0="inet xxx.xxx.xxx.1 netmask xxx.xxx.xxx.192" > ifconfig_wlan0_alias0="inet xxx.xxx.xxx.65 netmask xxx.xxx.xxx.192" > ifconfig_wlan0_alias1="inet xxx.xxx.xxx.129 netmask xxx.xxx.xxx.192" > ifconfig_wlan0_alias2="inet xxx.xxx.xxx.193 netmask xxx.xxx.xxx.192" > > NOTE, I found the order of items in create_args_wlan0 important. Yes, you cannot change the country code once the interface is marked UP and that happens implicitly when you set the ip address on an ifnet. > > ==== > > I also adjusted the 6.4 hostapd.conf. Changes in 8.0RC2 are shown with -> > ===== > interface=ath0 -> wlan0 > driver=bsd > -> country_code=Australia Not used by hostapd on freebsd (pretty sure). > logger_syslog=-1 > logger_syslog_level=0 > logger_stdout=-1 > logger_stdout_level=0 > debug=4 > dump_file=/tmp/hostapd.dump > ctrl_interface=/var/run/hostapd > ctrl_interface_group=wheel > ssid=netname > macaddr_acl=0 > ieee8021x=1 > own_ip_addr=127.0.0.1 > auth_server_addr=xxx.xxx.xxx.xxx > auth_server_port=1812 > auth_server_shared_secret=secretpw > wpa=1 > wpa_key_mgmt=WPA-EAP > wpa_pairwise=CCMP TKIP > === > > Extra debugging output from wlandebug: > > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv probe req > Nov 9 00:44:07 freebsd kernel: wlan0: send probe resp on channel 1 to > xx:xx:xx:xx:xx:xx > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv probe req > Nov 9 00:44:07 freebsd kernel: wlan0: send probe resp on channel 1 to > xx:xx:xx:xx:xx:xx > Nov 9 00:44:07 freebsd kernel: wlan0: received auth from xx:xx:xx:xx:xx:xx > rssi 24 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] recv auth frame > with algorithm 0 seq 1 > Nov 9 00:44:07 freebsd kernel: [xx:xx:xx:xx:xx:xx] send auth on channel 1 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station > authenticated (open) > Nov 9 00:44:07 freebsd kernel: wlan0: received assoc_req from > xx:xx:xx:xx:xx:xx rssi 24 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] WPA ie: mc 1/0 uc > 3/0 key 1 caps 0x0 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station associated > at aid 1: short preamble, short slot time, QoS > Nov 9 00:44:07 freebsd kernel: [xx:xx:xx:xx:xx:xx] send assoc_resp on channel > 1 > Nov 9 00:44:07 freebsd kernel: wlan0: [xx:xx:xx:xx:xx:xx] station unauthorize > via MLME So your station associated and hostapd saw it but nothing in your logs shows what hostapd did or did not do to complete the radius handshake. All we see is that hostapd dropped the station--presumably because it timed out trying to authenticated against the backend. Not sure what debug level you need for hostapd; I usually use the cmd line options. Sam From attilio at freebsd.org Sun Nov 8 21:01:41 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Nov 8 21:01:48 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: Message-ID: <3bbf2fe10911081301t13b31458g8c18d57c70661e47@mail.gmail.com> 2009/10/23 Jaime Bozza : > I believe I found a problem with the ULE scheduler - At least the fact that there is a problem, but I'm not sure where to go from here. The system locks all processes, but doesn't panic, so I have no output to give. > > I was able to duplicate this on three different machines and solved it by switching to the scheduler to 4BSD. > > Here's the environment: > > FreeBSD 7.2 i386, installed from bootonly ISO, Custom install, minimal, no other changes other than setting timezone, changing root password, and turning on sshd (allowing root and password connection). Did you recompile your kernel? Can you show me the revision of src/sys/kern/sched_ule.c you used? Attilio -- Peace can only be achieved by understanding - A. Einstein From sven at hazejager.nl Mon Nov 9 18:14:26 2009 From: sven at hazejager.nl (Sven Hazejager) Date: Mon Nov 9 18:14:33 2009 Subject: Serial console not working in 7.2-p4 and 7.2-STABLE Message-ID: <8ffccde70911090952s2349c633u61c96e5183cb8116@mail.gmail.com> All, I'm pulling my hair out on this one! Can't get the serial console to work with nanoBSD, either 7.2-p4 or 7-STABLE. A 8.0 nanoBSD image works fine (which I have not created myself). The symptom is that all kernel output goes to VGA. Whatever I do. This happens in VMware Player (where I actually see the VGA output) and on my ALIX (Soekris-like) board (which does not have a VGA card). boot0 is boot0sio, boot.config contains -h and the loader works fine over the serial port. console=comconsole there so that should work, right? No, because still my kernel outputs everything to VGA... I'm using the sio device. Even tried putting flags on 0x30 -> no difference at all. Tried the uart device and removing sio from my kernel but that resulted in having NO serial ports at all... Any help is much appreciated! Sven From crapsh at monkeybrains.net Mon Nov 9 22:26:24 2009 From: crapsh at monkeybrains.net (Rudy) Date: Mon Nov 9 22:26:30 2009 Subject: Tunnel IPv6 requests to my IPv4 servers? Message-ID: <4AF8970F.60909@monkeybrains.net> I got my first IPv6 from ARIN. I set up my router and am successfully advertising my IPv6 block. On my DNS server, I added an IPv6 IP, no problem (try pinging! ns1.monkeybrains.net). Now, I'd like to 'NAT' to some older boxes and not mess with actually putting IPv6 IPs on those boxes. Say I had a box with running IPv4 with: 69.147.83.40 How would I 'nat' or 'gif' or 'tunnel' from a NAT box without putting any IPv6 on 69.147.83.40? I want to have: 2607:f598:0:1::666 on my 'firewall' and have it tunnel to 69.147.83.40 or whatever.... I've read this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html But that seems more geared toward getting IPv6 on clients. Rudy From kenyon at kenyonralph.com Mon Nov 9 22:47:53 2009 From: kenyon at kenyonralph.com (Kenyon Ralph) Date: Mon Nov 9 22:47:59 2009 Subject: Tunnel IPv6 requests to my IPv4 servers? In-Reply-To: <4AF8970F.60909@monkeybrains.net> References: <4AF8970F.60909@monkeybrains.net> Message-ID: <20091109224750.GB15054@kenyonralph.com> On 2009-11-09T14:26:23-0800, Rudy wrote: > I got my first IPv6 from ARIN. I set up my router and am > successfully advertising my IPv6 block. On my DNS server, I added > an IPv6 IP, no problem (try pinging! ns1.monkeybrains.net). Now, > I'd like to 'NAT' to some older boxes and not mess with actually > putting IPv6 IPs on those boxes. Say I had a box with running IPv4 > with: 69.147.83.40 > How would I 'nat' or 'gif' or 'tunnel' from a NAT box without > putting any IPv6 on 69.147.83.40? > > I want to have: > 2607:f598:0:1::666 on my 'firewall' and have it tunnel to > 69.147.83.40 or whatever.... > I've read this: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html > But that seems more geared toward getting IPv6 on clients. Are you trying to give the older boxes IPv6 connectivity or IPv4 connectivity to the Internet? If IPv6, why not just give the older boxes IPv6 addresses? Seems to me it would be a lot easier than messing with tunneling. They don't even need globally routeable IPv4 addresses. Set up rtadvd on your router, allow them to use their automatic IPv6 addresses (or set the addresses manually, doesn't matter), and that should be it. It shouldn't be that hard, since ease of setup is one of the things IPv6 is designed for. On FreeBSD, ipv6_enable="YES" is probably all you need to do. -- Kenyon Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091109/20d6f060/attachment.pgp From dougb at FreeBSD.org Tue Nov 10 03:21:10 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Nov 10 03:21:17 2009 Subject: Tunnel IPv6 requests to my IPv4 servers? In-Reply-To: <20091109224750.GB15054@kenyonralph.com> References: <4AF8970F.60909@monkeybrains.net> <20091109224750.GB15054@kenyonralph.com> Message-ID: <4AF8DC23.3040007@FreeBSD.org> Kenyon Ralph wrote: > On 2009-11-09T14:26:23-0800, Rudy wrote: >> I got my first IPv6 from ARIN. I set up my router and am >> successfully advertising my IPv6 block. On my DNS server, I added >> an IPv6 IP, no problem (try pinging! ns1.monkeybrains.net). Now, >> I'd like to 'NAT' to some older boxes and not mess with actually >> putting IPv6 IPs on those boxes. Say I had a box with running IPv4 >> with: 69.147.83.40 >> How would I 'nat' or 'gif' or 'tunnel' from a NAT box without >> putting any IPv6 on 69.147.83.40? >> >> I want to have: >> 2607:f598:0:1::666 on my 'firewall' and have it tunnel to >> 69.147.83.40 or whatever.... >> I've read this: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html >> But that seems more geared toward getting IPv6 on clients. > > Are you trying to give the older boxes IPv6 connectivity or IPv4 > connectivity to the Internet? > > If IPv6, why not just give the older boxes IPv6 addresses? Seems to me > it would be a lot easier than messing with tunneling. They don't even > need globally routeable IPv4 addresses. Set up rtadvd on your router, > allow them to use their automatic IPv6 addresses (or set the addresses > manually, doesn't matter), and that should be it. It shouldn't be that > hard, since ease of setup is one of the things IPv6 is designed for. On > FreeBSD, ipv6_enable="YES" is probably all you need to do. Without knowing what you're trying to accomplish I'd have to agree with Kenyon. One nice thing about IPv6 is that NAT is no longer needed, it would probably be better if you didn't try to subvert the protocol design. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From brian.scott4 at det.nsw.edu.au Tue Nov 10 05:59:36 2009 From: brian.scott4 at det.nsw.edu.au (Scott, Brian) Date: Tue Nov 10 05:59:44 2009 Subject: Tunnel IPv6 requests to my IPv4 servers? In-Reply-To: <4AF8970F.60909@monkeybrains.net> Message-ID: In a word, 6tunnel. It's an application level proxy that does the job well enough to get you out of trouble. Another approach would be to run netcat (nc) from inetd on the port in question. That said, I'll add my voice to the suggestion that it is very simple to get IPv6 going on pretty much anything (OK, probably a pain on windows 2000 but even there it is theoretically possible). Rather than doing NAT, you simply apply policy with your firewall rules where it should always have been. Brian -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Rudy Sent: Tuesday, 10 November 2009 9:26 AM To: freebsd-stable@freebsd.org Subject: Tunnel IPv6 requests to my IPv4 servers? I got my first IPv6 from ARIN. I set up my router and am successfully advertising my IPv6 block. On my DNS server, I added an IPv6 IP, no problem (try pinging! ns1.monkeybrains.net). Now, I'd like to 'NAT' to some older boxes and not mess with actually putting IPv6 IPs on those boxes. Say I had a box with running IPv4 with: 69.147.83.40 How would I 'nat' or 'gif' or 'tunnel' from a NAT box without putting any IPv6 on 69.147.83.40? I want to have: 2607:f598:0:1::666 on my 'firewall' and have it tunnel to 69.147.83.40 or whatever.... I've read this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.h tml But that seems more geared toward getting IPv6 on clients. Rudy _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From danny at cs.huji.ac.il Tue Nov 10 06:47:40 2009 From: danny at cs.huji.ac.il (Daniel Braniss) Date: Tue Nov 10 06:47:47 2009 Subject: Serial console not working in 7.2-p4 and 7.2-STABLE In-Reply-To: Your message of Mon, 9 Nov 2009 18:52:58 +0100 . Message-ID: > All, > > I'm pulling my hair out on this one! Can't get the serial console to > work with nanoBSD, either 7.2-p4 or 7-STABLE. A 8.0 nanoBSD image > works fine (which I have not created myself). The symptom is that all > kernel output goes to VGA. Whatever I do. This happens in VMware > Player (where I actually see the VGA output) and on my ALIX > (Soekris-like) board (which does not have a VGA card). > > boot0 is boot0sio, boot.config contains -h and the loader works fine > over the serial port. console=comconsole there so that should work, > right? No, because still my kernel outputs everything to VGA... > > I'm using the sio device. Even tried putting flags on 0x30 -> no > difference at all. Tried the uart device and removing sio from my > kernel but that resulted in having NO serial ports at all... > > Any help is much appreciated! > > Sven hi, put hint.uart.0.flags="0x10" in /boot/device.hints, or better, make sure you have an updated one from /sys/i386/conf/GENERIC.hints another thing, make sure the speed/bauds is correct, else you probably wont see any output either in /boot/loader.conf you need console="comconsole,vidconsole" and comconsole_speed="115200" to set the speed. to get a login you will need, in /etc/ttys: ttyu0 "/usr/libexec/getty 3wire.115200" dialup on secure hope this helps danny From ivoras at freebsd.org Tue Nov 10 15:29:48 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Nov 10 15:29:56 2009 Subject: 8.0RC2 "top" statistics seem broken Message-ID: Here is what I'm seeing now: last pid: 70893; load averages: 1.70, 1.10, 0.58 up 27+02:59:26 16:23:59 134 processes: 3 running, 131 sleeping CPU: 94.8% user, 0.0% nice, 4.6% system, 0.6% interrupt, 0.0% idle Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free Swap: 640M Total, 205M Used, 435M Free, 32% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 751 pgsql 1 45 0 159M 556K select 1 249:38 0.00% postgres 756 pgsql 1 44 0 25004K 600K select 1 86:31 0.00% postgres 754 pgsql 1 44 0 159M 1040K select 1 13:02 0.00% postgres 753 pgsql 1 44 0 159M 7868K select 1 10:55 0.00% postgres 597 root 1 44 0 3184K 464K select 0 4:49 0.00% syslogd 755 pgsql 1 44 0 159M 1432K select 1 4:46 0.00% postgres 659 root 1 44 0 62156K 1356K select 1 4:30 0.00% vmware-guestd 765 nobody 1 4 0 3236K 192K kqread 1 3:25 0.00% memcached 775 root 1 44 0 9996K 340K select 1 2:18 0.00% httpd 900 sveb 1 5 0 9452K 0K select 0 1:49 0.00% 790 www 1 44 0 9768K 224K select 1 1:47 0.00% httpd 70851 ivoras 3 96 0 199M 195M CPU0 0 1:47 0.00% 7z Load average and %CPU user are right, as are other global statistics. The load is produced by the "7z" process (archivers/p7zip) which compresses some data in two threads but is credited with 0% CPU, though its runtime is correct (increments every second as it should in a CPU-bound process). It doesn't help if I expand / show individual threads. From freebsd at jdc.parodius.com Tue Nov 10 15:48:45 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Tue Nov 10 15:48:52 2009 Subject: 8.0RC2 "top" statistics seem broken In-Reply-To: References: Message-ID: <20091110154842.GA63937@icarus.home.lan> On Tue, Nov 10, 2009 at 04:29:37PM +0100, Ivan Voras wrote: > Here is what I'm seeing now: > > > last pid: 70893; load averages: 1.70, 1.10, 0.58 > up 27+02:59:26 16:23:59 > 134 processes: 3 running, 131 sleeping > CPU: 94.8% user, 0.0% nice, 4.6% system, 0.6% interrupt, 0.0% idle > Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free > Swap: 640M Total, 205M Used, 435M Free, 32% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 751 pgsql 1 45 0 159M 556K select 1 249:38 0.00% postgres > 756 pgsql 1 44 0 25004K 600K select 1 86:31 0.00% postgres > 754 pgsql 1 44 0 159M 1040K select 1 13:02 0.00% postgres > 753 pgsql 1 44 0 159M 7868K select 1 10:55 0.00% postgres > 597 root 1 44 0 3184K 464K select 0 4:49 0.00% syslogd > 755 pgsql 1 44 0 159M 1432K select 1 4:46 0.00% postgres > 659 root 1 44 0 62156K 1356K select 1 4:30 0.00% vmware-guestd > 765 nobody 1 4 0 3236K 192K kqread 1 3:25 0.00% memcached > 775 root 1 44 0 9996K 340K select 1 2:18 0.00% httpd > 900 sveb 1 5 0 9452K 0K select 0 1:49 0.00% > 790 www 1 44 0 9768K 224K select 1 1:47 0.00% httpd > 70851 ivoras 3 96 0 199M 195M CPU0 0 1:47 0.00% 7z > > > Load average and %CPU user are right, as are other global > statistics. The load is produced by the "7z" process > (archivers/p7zip) which compresses some data in two threads but is > credited with 0% CPU, though its runtime is correct (increments > every second as it should in a CPU-bound process). It doesn't help > if I expand / show individual threads. Does the behaviour change if you use "top -C" or "top -P" (doubting the latter)? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ivoras at freebsd.org Tue Nov 10 15:53:02 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Nov 10 15:53:09 2009 Subject: 8.0RC2 "top" statistics seem broken In-Reply-To: <20091110154842.GA63937@icarus.home.lan> References: <20091110154842.GA63937@icarus.home.lan> Message-ID: Jeremy Chadwick wrote: > > On Tue, Nov 10, 2009 at 04:29:37PM +0100, Ivan Voras wrote: >> Here is what I'm seeing now: >> >> >> last pid: 70893; load averages: 1.70, 1.10, 0.58 >> up 27+02:59:26 16:23:59 >> 134 processes: 3 running, 131 sleeping >> CPU: 94.8% user, 0.0% nice, 4.6% system, 0.6% interrupt, 0.0% idle >> Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free >> Swap: 640M Total, 205M Used, 435M Free, 32% Inuse >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 751 pgsql 1 45 0 159M 556K select 1 249:38 0.00% postgres >> 756 pgsql 1 44 0 25004K 600K select 1 86:31 0.00% postgres >> 754 pgsql 1 44 0 159M 1040K select 1 13:02 0.00% postgres >> 753 pgsql 1 44 0 159M 7868K select 1 10:55 0.00% postgres >> 597 root 1 44 0 3184K 464K select 0 4:49 0.00% syslogd >> 755 pgsql 1 44 0 159M 1432K select 1 4:46 0.00% postgres >> 659 root 1 44 0 62156K 1356K select 1 4:30 0.00% vmware-guestd >> 765 nobody 1 4 0 3236K 192K kqread 1 3:25 0.00% memcached >> 775 root 1 44 0 9996K 340K select 1 2:18 0.00% httpd >> 900 sveb 1 5 0 9452K 0K select 0 1:49 0.00% >> 790 www 1 44 0 9768K 224K select 1 1:47 0.00% httpd >> 70851 ivoras 3 96 0 199M 195M CPU0 0 1:47 0.00% 7z >> >> >> Load average and %CPU user are right, as are other global >> statistics. The load is produced by the "7z" process >> (archivers/p7zip) which compresses some data in two threads but is >> credited with 0% CPU, though its runtime is correct (increments >> every second as it should in a CPU-bound process). It doesn't help >> if I expand / show individual threads. > > Does the behaviour change if you use "top -C" or "top -P" (doubting > the latter)? No, same in all cases. From crapsh at monkeybrains.net Tue Nov 10 22:51:11 2009 From: crapsh at monkeybrains.net (Rudy) Date: Tue Nov 10 22:51:21 2009 Subject: Tunnel IPv6 requests to my IPv4 servers? In-Reply-To: References: Message-ID: <4AF9EE5B.6050709@monkeybrains.net> > That said, I'll add my voice to the suggestion that it is very simple to > get IPv6 going on pretty much anything Hmmm... half the boxes I host, I don't have a login to, yet for some odd reason, I want to make my network 100% IPv6 accessible. I manage two /22's so, I'm sitting on a pile of IPs. First off, I'm going to get a one-to-one mapping setup for every IP -- hopefully through 6tunnel (I'll look into that, thanks for the pointer). Second, I'll migrate to multiple IPs on boxes that I have access to / boxes that support IPv6. (Example: Pre FreeBSD 7.2 box jails only support one IP) Goal: 100% IPv6 ready, whether my customers want it or not! Rudy From geoff at apro.com.au Wed Nov 11 05:48:20 2009 From: geoff at apro.com.au (Geoff Roberts) Date: Wed Nov 11 05:48:27 2009 Subject: Problems moving hostapd AP config from 6.4 to 8.0RC2 In-Reply-To: <4AF6F669.6050403@freebsd.org> References: <200911090053.47239.geoff@apro.com.au> <4AF6F669.6050403@freebsd.org> Message-ID: <200911111648.00729.geoff@apro.com.au> Hi Sam, On Mon, 9 Nov 2009 03:48:41 am Sam Leffler wrote: > snip < > > So your station associated and hostapd saw it but nothing in your logs > shows what hostapd did or did not do to complete the radius handshake. > All we see is that hostapd dropped the station--presumably because it > timed out trying to authenticated against the backend. > > Not sure what debug level you need for hostapd; I usually use the cmd > line options. Thanks for responding - it was a great help. Your comment give me a clue as to where to begin looking. It appears some components required by hostapd weren't being built. I am building on an amd64 system. I had a look at the make file in /usr/src/usr.sbin/wpa/hostapd/Makefile and found that adding the following to /etc/src.conf fixed my problem: HOSTAPD_CFLAGS+=-DEAP_SERVER -DEAP_GTC -DEAP_AKA -DEAP_SIM -DEAP_GPSK HOSTAPD_CFLAGS+=-DEAP_PAX -DEAP_SAKE WITH_OPENSSL=YES I haven't had a chance to narrow down exactly which one made the difference, but I'm guessing it is the -DEAP_SERVER flag. The only tunable I could find in /usr/src/tools/build/options was WPA_SUPPLICANT_EAPOL, but this should only affect wpa_supplicant. Does anyone know if there is a tunable I am missing in my src.conf file, or should I be setting the HOSTAPD_CFLAGS directly as above. Kind regards, Geoff From sven at hazejager.nl Wed Nov 11 08:14:07 2009 From: sven at hazejager.nl (Sven Hazejager) Date: Wed Nov 11 08:14:16 2009 Subject: Serial console not working in 7.2-p4 and 7.2-STABLE In-Reply-To: <8ffccde70911090952s2349c633u61c96e5183cb8116@mail.gmail.com> References: <8ffccde70911090952s2349c633u61c96e5183cb8116@mail.gmail.com> Message-ID: <8ffccde70911110014ld74bafat1f3d8d3c514b136a@mail.gmail.com> On Mon, Nov 9, 2009 at 18:52, Sven Hazejager wrote: > I'm pulling my hair out on this one! Can't get the serial console to > work with nanoBSD, either 7.2-p4 or 7-STABLE. A 8.0 nanoBSD image > works fine (which I have not created myself). The symptom is that all > kernel output goes to VGA. Whatever I do. This happens in VMware > Player (where I actually see the VGA output) and on my ALIX > (Soekris-like) board (which does not have a VGA card). PROBLEM SOLVED! In an attempt to minimize FreeBSD for nanoBSD I had WITHOUT_FORTH=true in my /etc/src.conf. That apparently breaks the passing of boot flags to the kernel, which causes the kernel to use the VGA output even though boot.config has "-h" and console=comconsole in the loader. Thank you all for your comments and suggestions. Sven From freebsd at jdc.parodius.com Wed Nov 11 08:58:55 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Wed Nov 11 08:59:03 2009 Subject: Serial console not working in 7.2-p4 and 7.2-STABLE In-Reply-To: <8ffccde70911110014ld74bafat1f3d8d3c514b136a@mail.gmail.com> References: <8ffccde70911090952s2349c633u61c96e5183cb8116@mail.gmail.com> <8ffccde70911110014ld74bafat1f3d8d3c514b136a@mail.gmail.com> Message-ID: <20091111084543.GA84067@icarus.home.lan> On Wed, Nov 11, 2009 at 09:14:05AM +0100, Sven Hazejager wrote: > On Mon, Nov 9, 2009 at 18:52, Sven Hazejager wrote: > > I'm pulling my hair out on this one! Can't get the serial console to > > work with nanoBSD, either 7.2-p4 or 7-STABLE. A 8.0 nanoBSD image > > works fine (which I have not created myself). The symptom is that all > > kernel output goes to VGA. Whatever I do. This happens in VMware > > Player (where I actually see the VGA output) and on my ALIX > > (Soekris-like) board (which does not have a VGA card). > > PROBLEM SOLVED! > > In an attempt to minimize FreeBSD for nanoBSD I had WITHOUT_FORTH=true > in my /etc/src.conf. That apparently breaks the passing of boot flags > to the kernel, which causes the kernel to use the VGA output even > though boot.config has "-h" and console=comconsole in the loader. This would actually break a large portion of the FreeBSD bootstraps. I'd advocate that WITHOUT_FORTH be removed until the bootstraps are upgraded to something that doesn't rely on forth (if/when that ever happens). Otherwise, someone may want modify the framework involving src.conf to state that if WITHOUT_FORTH is defined, to bail on a build. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sam at errno.com Thu Nov 12 04:53:23 2009 From: sam at errno.com (Sam Leffler) Date: Thu Nov 12 04:53:31 2009 Subject: Problems moving hostapd AP config from 6.4 to 8.0RC2 In-Reply-To: <200911111648.00729.geoff@apro.com.au> References: <200911090053.47239.geoff@apro.com.au> <4AF6F669.6050403@freebsd.org> <200911111648.00729.geoff@apro.com.au> Message-ID: <4AFB94BD.5030800@errno.com> Geoff Roberts wrote: > Hi Sam, > > On Mon, 9 Nov 2009 03:48:41 am Sam Leffler wrote: >> snip < >> >> So your station associated and hostapd saw it but nothing in your logs >> shows what hostapd did or did not do to complete the radius handshake. >> All we see is that hostapd dropped the station--presumably because it >> timed out trying to authenticated against the backend. >> >> Not sure what debug level you need for hostapd; I usually use the cmd >> line options. > > Thanks for responding - it was a great help. > > Your comment give me a clue as to where to begin looking. > > It appears some components required by hostapd weren't being built. > > I am building on an amd64 system. > > I had a look at the make file in /usr/src/usr.sbin/wpa/hostapd/Makefile and > found that adding the following to /etc/src.conf fixed my problem: > > HOSTAPD_CFLAGS+=-DEAP_SERVER -DEAP_GTC -DEAP_AKA -DEAP_SIM -DEAP_GPSK > HOSTAPD_CFLAGS+=-DEAP_PAX -DEAP_SAKE > > WITH_OPENSSL=YES > > I haven't had a chance to narrow down exactly which one made the difference, > but I'm guessing it is the -DEAP_SERVER flag. > > The only tunable I could find in /usr/src/tools/build/options was > WPA_SUPPLICANT_EAPOL, but this should only affect wpa_supplicant. > > Does anyone know if there is a tunable I am missing in my src.conf file, or > should I be setting the HOSTAPD_CFLAGS directly as above. Setting HOSTAPD_CFLAGS directly is the intended mechanism. EAP_SERVER is the important one to define; past that you're just adding in some of the more esoteric mechanisms. I should probably enable it by default (it comes setup out of the box to do only WPA-PSK). Sam From invitations at linkedin.com Thu Nov 12 06:42:03 2009 From: invitations at linkedin.com (Olga Simurzina (LinkedIn Invitations)) Date: Thu Nov 12 06:42:10 2009 Subject: Reminder about your invitation from Olga Simurzina Message-ID: <1127379800.12638500.1258008122438.JavaMail.app@ech3-cdn09.prod> LinkedIn ------------ This is a reminder that on October 30, Olga Simurzina sent you an invitation to become part of their professional network at LinkedIn. Follow this link to accept Olga Simurzina's invitation. https://www.linkedin.com/e/isd/830468504/Ss8Egzu5/ Signing up is free and takes less than a minute. This is a reminder that on October 30, Olga Simurzina wrote: > To: [freebsd-stable@freebsd.org] > From: Olga Simurzina [simurzina.o@yandex.ru] > Subject: UKRAINIAN ART WEEK > > ??????! ?????????? ??? ?? ????????????? ????????-??????? > ???????????? ????????? ??????????? ?????? ???????? / Ukrainian Art Week?, > ??????? ??????? ? ????? 17-23 ?????? 2009 ????. > ????? ??????????? ??? ????, ??? ? ??????! > ?????????? ????????? ?????????? ?????? ???????? ????????: > 1)????????????? ??????? ???????? > 2)????????????? ??????? ?? ??????? ? ???????????? ??????? > 3)????????????? ??????? ?????????? > 4)????????????? ??????? ?????????? > 5)????????????? ??????? ???????????-??????????? ????????? > ??????????? ???? ?????????? ?????? ????????: www.artweek.org > ???? ???? ???????? ?? ???? ???????. > ? ?????????, ????? ????????? > ???.? ?????: +38 (097) 6751931, +38 (063) 5693832, > Email: info@artweek.org ICQ 439-001-943 > ================================================== > Dear friend! I am pleased to invite you to UKRAINIAN ART WEEK > (November 17-23, 2009, in Kiev, Ukraine). > It's an International Exhibition and Competition of Contemporary Arts. > You can participate - ONLINE or PERSONALLY. > Ukrainian Art Week brings together two programs - an exhibition and contest. > All works are presented in the heart of Kiev - in the Central Exhibition Hall > and published in the International folder "New Faces in Arts". > The UKRAINIAN ART WEEK program includes: > 1) Painting Competition > 2) Graphic & Graphic Design Competition > 3) Photography Competition > 4) Sculpture Competition > 5) Crafts Competition > If you are interested in this project - please contact me info@artweek.org > Our Website: www.artweek.org or www.artweek.eu > My mobile: +38(097)6751931, +38 (063) 5693832, > CYA, Olga Sydorenko The only way to get access to Olga Simurzina's professional network is through the following link: https://www.linkedin.com/e/isd/830468504/Ss8Egzu5/ You can remove yourself from Olga Simurzina's network at any time. -------------- ------ (c) 2009, LinkedIn Corporation From is at rambler-co.ru Thu Nov 12 07:16:21 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Thu Nov 12 07:16:29 2009 Subject: 8.0RC2 "top" statistics seem broken In-Reply-To: References: Message-ID: <20091112071618.GB81250@rambler-co.ru> On Tue, Nov 10, 2009 at 04:29:37PM +0100, Ivan Voras wrote: > Here is what I'm seeing now: > > > last pid: 70893; load averages: 1.70, 1.10, 0.58 > up > 27+02:59:26 16:23:59 > 134 processes: 3 running, 131 sleeping > CPU: 94.8% user, 0.0% nice, 4.6% system, 0.6% interrupt, 0.0% idle > Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free > Swap: 640M Total, 205M Used, 435M Free, 32% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 751 pgsql 1 45 0 159M 556K select 1 249:38 0.00% postgres > 756 pgsql 1 44 0 25004K 600K select 1 86:31 0.00% postgres > 754 pgsql 1 44 0 159M 1040K select 1 13:02 0.00% postgres > 753 pgsql 1 44 0 159M 7868K select 1 10:55 0.00% postgres > 597 root 1 44 0 3184K 464K select 0 4:49 0.00% syslogd > 755 pgsql 1 44 0 159M 1432K select 1 4:46 0.00% postgres > 659 root 1 44 0 62156K 1356K select 1 4:30 0.00% > vmware-guestd > 765 nobody 1 4 0 3236K 192K kqread 1 3:25 0.00% memcached > 775 root 1 44 0 9996K 340K select 1 2:18 0.00% httpd > 900 sveb 1 5 0 9452K 0K select 0 1:49 0.00% > 790 www 1 44 0 9768K 224K select 1 1:47 0.00% httpd > 70851 ivoras 3 96 0 199M 195M CPU0 0 1:47 0.00% 7z > > > Load average and %CPU user are right, as are other global statistics. > The load is produced by the "7z" process (archivers/p7zip) which > compresses some data in two threads but is credited with 0% CPU, though > its runtime is correct (increments every second as it should in a > CPU-bound process). It doesn't help if I expand / show individual threads. I believe this is related to multithreaded processes only. I saw this for intr kernel process. Singlethread processes eat CPU slightly less than on 7.2, however, I can not say is it statistic errors or real speedup. I saw the issue on SMP/ULE only and can not say anything about UP and 4BSD scheduler. -- Igor Sysoev http://sysoev.ru/en/ From Hans.F.Nordhaug at hiMolde.no Thu Nov 12 10:33:12 2009 From: Hans.F.Nordhaug at hiMolde.no (Hans F. Nordhaug) Date: Thu Nov 12 10:33:21 2009 Subject: /bin/sh core dumps on FreeBSD 7.2 Message-ID: <20091112103308.GA2536@hiMolde.no> Hi! Suddenly /bin/sh started to crash all the time with core dumps. I'm running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything lately. The /bin/sh binary seems to be untouched. It might be some hardware trouble, but the machine seems to run OK now. (I had to replace /bin/sh with a symlink to /rescue/sh.) I would like to track down the problem, but running sh I only get "Segmentation fault: 11 (core dumped)". I would be happy to run gdb and give you a backtrace. Any clues? Hans PS! I tried to run "freebsd-update IDS" to see if any files are broken, but it stops at Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output error From ivoras at freebsd.org Thu Nov 12 10:36:04 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 10:36:20 2009 Subject: /bin/sh core dumps on FreeBSD 7.2 In-Reply-To: <20091112103308.GA2536@hiMolde.no> References: <20091112103308.GA2536@hiMolde.no> Message-ID: Hans F. Nordhaug wrote: > Hi! > > Suddenly /bin/sh started to crash all the time with core dumps. I'm > running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything > lately. The /bin/sh binary seems to be untouched. It might be some > hardware trouble, but the machine seems to run OK now. (I had to > replace /bin/sh with a symlink to /rescue/sh.) > > I would like to track down the problem, but running sh I only get > "Segmentation fault: 11 (core dumped)". I would be happy to run > gdb and give you a backtrace. Any clues? > > Hans > > PS! I tried to run "freebsd-update IDS" to see if any files are > broken, but it stops at > Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output error All of this points to a hardware problem. I think the best thing you can try is to manually get a hash fingerprint of your sh and compare it with another, known good copy. From michal at sharescope.co.uk Thu Nov 12 10:46:25 2009 From: michal at sharescope.co.uk (Michal) Date: Thu Nov 12 10:46:32 2009 Subject: /bin/sh core dumps on FreeBSD 7.2 In-Reply-To: References: <20091112103308.GA2536@hiMolde.no> Message-ID: <4AFBE77A.8060605@sharescope.co.uk> Ivan Voras wrote: > Hans F. Nordhaug wrote: >> Hi! >> >> Suddenly /bin/sh started to crash all the time with core dumps. I'm >> running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything >> lately. The /bin/sh binary seems to be untouched. It might be some >> hardware trouble, but the machine seems to run OK now. (I had to >> replace /bin/sh with a symlink to /rescue/sh.) >> >> I would like to track down the problem, but running sh I only get >> "Segmentation fault: 11 (core dumped)". I would be happy to run >> gdb and give you a backtrace. Any clues? >> >> Hans >> >> PS! I tried to run "freebsd-update IDS" to see if any files are >> broken, but it stops at >> Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: >> Input/output error > > All of this points to a hardware problem. > Last time I saw things like this it was either a hard drive on the way out, or a PSU dying. Run some pre-OS tests (Ultimate boot cd or something) to try and get some results outside of the OS > I think the best thing you can try is to manually get a hash fingerprint > of your sh and compare it with another, known good copy. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From freebsd at jdc.parodius.com Thu Nov 12 11:53:52 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 12 11:53:59 2009 Subject: /bin/sh core dumps on FreeBSD 7.2 In-Reply-To: <20091112103308.GA2536@hiMolde.no> References: <20091112103308.GA2536@hiMolde.no> Message-ID: <20091112115350.GA18542@icarus.home.lan> On Thu, Nov 12, 2009 at 11:33:08AM +0100, Hans F. Nordhaug wrote: > Suddenly /bin/sh started to crash all the time with core dumps. I'm > running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything > lately. The /bin/sh binary seems to be untouched. It might be some > hardware trouble, but the machine seems to run OK now. (I had to > replace /bin/sh with a symlink to /rescue/sh.) > > I would like to track down the problem, but running sh I only get > "Segmentation fault: 11 (core dumped)". I would be happy to run > gdb and give you a backtrace. Any clues? > > PS! I tried to run "freebsd-update IDS" to see if any files are > broken, but it stops at > Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output error Hardware problem. Take your pick: bad RAM, bad hard disk, bad motherboard, bad PSU, bad cabling. You can rule out hard disk problems by installing smartmontools from ports (sysutils/smartmontools). Please provide output from the following command: smartctl -a /dev/{disk} Where {disk} is "ad4", "da0", or similar -- and NOT something like "ad8s1" or "da0s1d". If multiple disks are in your machine -- the one you want is the disk you boot from (where /boot exists, and/or root filesystem). I can teach you how to decode/read SMART statistics correctly. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ivoras at freebsd.org Thu Nov 12 12:25:31 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 12:25:38 2009 Subject: SMART In-Reply-To: <20091112115350.GA18542@icarus.home.lan> References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> Message-ID: Jeremy Chadwick wrote: > I can teach you how to decode/read SMART statistics correctly. > Actually, it would be good if you taught more than him :) I've always wondered how important are each of the dozen or so statistics and what indicates what... Here is for example my desktop drive: SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 087 083 006 Pre-fail Always - 45398197 3 Spin_Up_Time 0x0003 096 093 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 64 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 247407473 9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 10155 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 64 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 058 055 045 Old_age Always - 42 (Lifetime Min/Max 37/44) 194 Temperature_Celsius 0x0022 042 045 000 Old_age Always - 42 (0 20 0 0) 195 Hardware_ECC_Recovered 0x001a 062 059 000 Old_age Always - 45398197 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 I see many values exceeding threshold but since I see it so often on other drives I don't know what the threshold is for. From serenity at exscape.org Thu Nov 12 12:29:41 2009 From: serenity at exscape.org (Thomas Backman) Date: Thu Nov 12 12:29:49 2009 Subject: SMART In-Reply-To: References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> Message-ID: <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> On Nov 12, 2009, at 1:25 PM, Ivan Voras wrote: > Actually, it would be good if you taught more than him :) > > I've always wondered how important are each of the dozen or so statistics and what indicates what... > > Here is for example my desktop drive: > > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 087 083 006 Pre-fail Always - 45398197 > 3 Spin_Up_Time 0x0003 096 093 000 Pre-fail Always - 0 > 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 64 > 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 > 7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 247407473 > 9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 10155 > 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 64 > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 > 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 > 190 Airflow_Temperature_Cel 0x0022 058 055 045 Old_age Always - 42 (Lifetime Min/Max 37/44) > 194 Temperature_Celsius 0x0022 042 045 000 Old_age Always - 42 (0 20 0 0) > 195 Hardware_ECC_Recovered 0x001a 062 059 000 Old_age Always - 45398197 > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 > 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 > > I see many values exceeding threshold but since I see it so often on other drives I don't know what the threshold is for. None of the your values are exceeding the threshold - it works backwards. If the value is LOWER than the threshold, you might be in trouble. Also, judging by the raw read error rate, seek error rate and hardward ECC recovered, allow me to guess that this is a Seagate drive. :-) (Seagate drives, perhaps among others, use these raw values way differently than others. My Hitachi 7K1000.B has 0 on those.) Regards, Thomas From ivoras at freebsd.org Thu Nov 12 12:56:39 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 12:56:46 2009 Subject: SMART In-Reply-To: <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> Message-ID: Thomas Backman wrote: > On Nov 12, 2009, at 1:25 PM, Ivan Voras wrote: >> Actually, it would be good if you taught more than him :) >> >> I've always wondered how important are each of the dozen or so statistics and what indicates what... >> >> Here is for example my desktop drive: >> >> SMART Attributes Data Structure revision number: 10 >> Vendor Specific SMART Attributes with Thresholds: >> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE >> 1 Raw_Read_Error_Rate 0x000f 087 083 006 Pre-fail Always - 45398197 >> 3 Spin_Up_Time 0x0003 096 093 000 Pre-fail Always - 0 >> 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 64 >> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 >> 7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 247407473 >> 9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 10155 >> 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 >> 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 64 >> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 >> 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 >> 190 Airflow_Temperature_Cel 0x0022 058 055 045 Old_age Always - 42 (Lifetime Min/Max 37/44) >> 194 Temperature_Celsius 0x0022 042 045 000 Old_age Always - 42 (0 20 0 0) >> 195 Hardware_ECC_Recovered 0x001a 062 059 000 Old_age Always - 45398197 >> 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 >> 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 >> 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 >> 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 >> 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 >> >> I see many values exceeding threshold but since I see it so often on other drives I don't know what the threshold is for. > None of the your values are exceeding the threshold - it works backwards. If the value is LOWER than the threshold, you might be in trouble. Good to know. > Also, judging by the raw read error rate, seek error rate and hardward ECC recovered, allow me to guess that this is a Seagate drive. :-) > (Seagate drives, perhaps among others, use these raw values way differently than others. My Hitachi 7K1000.B has 0 on those.) Yes, it's Seagate. Statistically I have the least problems with their drives. But I imagine that lack of standardization about these statistics very much limits the usability of SMART, right? From geoff at apro.com.au Thu Nov 12 13:02:14 2009 From: geoff at apro.com.au (Geoff Roberts) Date: Thu Nov 12 13:02:21 2009 Subject: Problems moving hostapd AP config from 6.4 to 8.0RC2 In-Reply-To: <4AFB94BD.5030800@errno.com> References: <200911090053.47239.geoff@apro.com.au> <200911111648.00729.geoff@apro.com.au> <4AFB94BD.5030800@errno.com> Message-ID: <200911130001.41150.geoff@apro.com.au> Hi Sam, On Thu, 12 Nov 2009 03:53:17 pm Sam Leffler wrote: > Setting HOSTAPD_CFLAGS directly is the intended mechanism. EAP_SERVER > is the important one to define; past that you're just adding in some of > the more esoteric mechanisms. I should probably enable it by default > (it comes setup out of the box to do only WPA-PSK). Making a tunable that defaults to enabled sounds logical as the example files have references to it. However I can understand the concern in doing something different to the "shrink wrapped" edition :) It would possibly make a sensible companion setting for WPA_SUPPLICANT_EAPOL - HOSTAPD_EAP? Kind regards, Geoff -- ___________________________________ From the desk of Geoff Roberts Implementation Partner AUSTRALIAN PROJECTS PTY LIMITED S A F E ? K N O W L E D G E IT Security - Data Protection Email: support@apro.com.au NATIONAL HELP DESK SUPPORT Sydney ? ? ? ? ?02 4231 4222 Melbourne ? ? ? 03 9017 8222 Adelaide ? ? ? ?08 6461 6222 Perth ? ? ? ? ? 08 8463 1222 Brisbane ? ? ? ?07 3137 1555 Hobart ? ? ? ? ?03 6281 2555 Canberra ? ? ? ?02 6112 8855 ___________________________________ From bruce at cran.org.uk Thu Nov 12 13:31:54 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Nov 12 13:32:01 2009 Subject: SMART In-Reply-To: References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> Message-ID: <20091112133221.00006b43@unknown> On Thu, 12 Nov 2009 13:56:16 +0100 Ivan Voras wrote: > Yes, it's Seagate. Statistically I have the least problems with their > drives. But I imagine that lack of standardization about these > statistics very much limits the usability of SMART, right? > The main problem with SMART appears to be that it's not an accurate predictor of drive failure, according to a study done at Google - see http://labs.google.com/papers/disk_failures.pdf -- Bruce Cran From ivoras at freebsd.org Thu Nov 12 13:35:42 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 13:35:49 2009 Subject: SMART In-Reply-To: <20091112133221.00006b43@unknown> References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> <20091112133221.00006b43@unknown> Message-ID: Bruce Cran wrote: > On Thu, 12 Nov 2009 13:56:16 +0100 > Ivan Voras wrote: > >> Yes, it's Seagate. Statistically I have the least problems with their >> drives. But I imagine that lack of standardization about these >> statistics very much limits the usability of SMART, right? > > The main problem with SMART appears to be that it's not an accurate > predictor of drive failure, according to a study done at Google - see > http://labs.google.com/papers/disk_failures.pdf I've seen it. But I don't remember if they addressed the problem of nonstandard interpretations of statistics? I do remember they said they buy from multiple drive vendors. From danny at cs.huji.ac.il Thu Nov 12 14:01:25 2009 From: danny at cs.huji.ac.il (Daniel Braniss) Date: Thu Nov 12 14:01:32 2009 Subject: can't boot table-8 on HP Proliant DL580 G5 Message-ID: Hi, the boot stops somewhare after probing ata0, so far playing with the BIOS (disabling stuff) does not help. BTW, linux boots ok (except it has problems with IPMI) So, any success stories there? danny From dimitry at andric.com Thu Nov 12 14:06:28 2009 From: dimitry at andric.com (Dimitry Andric) Date: Thu Nov 12 14:06:35 2009 Subject: SMART In-Reply-To: References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> <20091112133221.00006b43@unknown> Message-ID: <4AFC166B.1040502@andric.com> On 2009-11-12 14:35, Ivan Voras wrote: > I've seen it. But I don't remember if they addressed the problem of > nonstandard interpretations of statistics? Note the statistics you quoted are "Vendor Specific SMART Attributes", so it is quite logical for different vendors to have different statistics. :) From ivoras at freebsd.org Thu Nov 12 14:11:43 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 14:11:50 2009 Subject: SMART In-Reply-To: <4AFC166B.1040502@andric.com> References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> <20091112133221.00006b43@unknown> <4AFC166B.1040502@andric.com> Message-ID: Dimitry Andric wrote: > On 2009-11-12 14:35, Ivan Voras wrote: >> I've seen it. But I don't remember if they addressed the problem of >> nonstandard interpretations of statistics? > > Note the statistics you quoted are "Vendor Specific SMART Attributes", > so it is quite logical for different vendors to have different > statistics. :) I see your point :) Though I would hope that a statistics like: 1 Raw_Read_Error_Rate 0x000f 087 083 006 Pre-fail Always - 45398197 would have an equivalent across vendors :) I know, it's too much to ask :) From info at martenvijn.nl Thu Nov 12 14:26:37 2009 From: info at martenvijn.nl (Marten Vijn) Date: Thu Nov 12 14:26:52 2009 Subject: 8.0-rc2 meshmode breaks hostap mode on ath0 Message-ID: <1258035995.4826.0.camel@mvn-desktop> hi 8.0-rc2 802.11s breaks ap mode: - on the same interface - when mesh is on diffent channel how-to reproduce: ifconfig wlan0 create wlandev ath0 wlanmode hostap ifconfig wlan0 ssid bert channel 3 up ifconfig wlan1 create wlandev ath0 wlanmode mesh ifconfig wlan1 channel 3 meshid ernie up ifconfig ==> wlan0 => status: running ifconfig wlan1 channel 7 ifconfig ==> wlan0 => status: no carrier details below, kind regards, Marten dmesg: # dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RC2 #0: Tue Nov 10 20:24:18 CET 2009 root@master:/usr/obj/nanobsd.full/usr/src/sys/KERNEL i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x494 Stepping = 4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 55230464 (52 MB) wlan: mac acl policy registered kbd1 at kbdmux0 ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. *** WARNING: missing CPU_ELAN -- timekeeping may be wrong pcib0: pcibus 0 on motherboard pci0: on pcib0 ath0: mem 0xa0000000-0xa000ffff irq 10 at device 16.0 on pci0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 sis0: port 0xe000-0xe0ff mem 0xa0010000-0xa0010fff irq 11 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c5:59:8c sis0: [ITHREAD] sis1: port 0xe100-0xe1ff mem 0xa0011000-0xa0011fff irq 5 at device 19.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c5:59:8d sis1: [ITHREAD] sis2: port 0xe200-0xe2ff mem 0xa0012000-0xa0012fff irq 9 at device 20.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c5:59:8e sis2: [ITHREAD] cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to get the current command byte value. atrtc0: at port 0x70 irq 8 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounters tick every 1.000 msec ad0: 1923MB at ata0-master PIO4 Trying to mount root from ufs:/dev/ad0s1a Invalid time in real time clock. Check and reset the date immediately! wlan0: Ethernet address: 00:0b:6b:34:58:99 wlan1: Ethernet address: 00:0b:6b:34:58:99 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Uptime: 9m38s Rebooting... Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RC2 #0: Tue Nov 10 20:24:18 CET 2009 root@master:/usr/obj/nanobsd.full/usr/src/sys/KERNEL i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x4f4 Stepping = 4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 55230464 (52 MB) wlan: mac acl policy registered kbd1 at kbdmux0 ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. *** WARNING: missing CPU_ELAN -- timekeeping may be wrong pcib0: pcibus 0 on motherboard pci0: on pcib0 ath0: mem 0xa0000000-0xa000ffff irq 10 at device 16.0 on pci0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 sis0: port 0xe000-0xe0ff mem 0xa0010000-0xa0010fff irq 11 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c5:59:8c sis0: [ITHREAD] sis1: port 0xe100-0xe1ff mem 0xa0011000-0xa0011fff irq 5 at device 19.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c5:59:8d sis1: [ITHREAD] sis2: port 0xe200-0xe2ff mem 0xa0012000-0xa0012fff irq 9 at device 20.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c5:59:8e sis2: [ITHREAD] cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to get the current command byte value. atrtc0: at port 0x70 irq 8 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounters tick every 1.000 msec ad0: 1923MB at ata0-master PIO4 Trying to mount root from ufs:/dev/ad0s1a Invalid time in real time clock. Check and reset the date immediately! # tail -n 40 /var/log/messages Nov 10 19:31:30 kernel: nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Nov 10 19:31:30 kernel: sis1: Ethernet address: 00:00:24:c5:59:8d Nov 10 19:31:30 kernel: sis1: [ITHREAD] Nov 10 19:31:30 kernel: sis2: port 0xe200-0xe2ff mem 0xa0012000-0xa0012fff irq 9 at device 20.0 on pci0 Nov 10 19:31:30 kernel: sis2: Silicon Revision: DP83816A Nov 10 19:31:30 kernel: miibus2: on sis2 Nov 10 19:31:30 kernel: nsphyter2: PHY 0 on miibus2 Nov 10 19:31:30 kernel: nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Nov 10 19:31:30 kernel: sis2: Ethernet address: 00:00:24:c5:59:8e Nov 10 19:31:30 kernel: sis2: [ITHREAD] Nov 10 19:31:30 kernel: cpu0 on motherboard Nov 10 19:31:30 kernel: isa0: on motherboard Nov 10 19:31:30 kernel: pmtimer0 on isa0 Nov 10 19:31:30 kernel: orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 Nov 10 19:31:30 kernel: ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 Nov 10 19:31:30 kernel: ata0: [ITHREAD] Nov 10 19:31:30 kernel: ata1 at port 0x170-0x177,0x376 irq 15 on isa0 Nov 10 19:31:30 kernel: ata1: [ITHREAD] Nov 10 19:31:30 kernel: atkbdc0: at port 0x60,0x64 on isa0 Nov 10 19:31:30 kernel: atkbd0: irq 1 on atkbdc0 Nov 10 19:31:30 kernel: kbd0 at atkbd0 Nov 10 19:31:30 kernel: atkbd0: [GIANT-LOCKED] Nov 10 19:31:30 kernel: atkbd0: [ITHREAD] Nov 10 19:31:30 kernel: psm0: unable to get the current command byte value. Nov 10 19:31:30 kernel: atrtc0: at port 0x70 irq 8 on isa0 Nov 10 19:31:30 kernel: uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Nov 10 19:31:30 kernel: uart0: [FILTER] Nov 10 19:31:30 kernel: uart0: console (9600,n,8,1) Nov 10 19:31:30 kernel: uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 Nov 10 19:31:30 kernel: uart1: [FILTER] Nov 10 19:31:30 kernel: Timecounters tick every 1.000 msec Nov 10 19:31:30 kernel: ad0: 1923MB at ata0-master PIO4 Nov 10 19:31:30 kernel: Trying to mount root from ufs:/dev/ad0s1a Nov 10 19:31:30 kernel: Invalid time in real time clock. Nov 10 19:31:30 kernel: Check and reset the date immediately! Nov 10 19:31:54 login: ROOT LOGIN (root) ON ttyu0 Nov 10 19:32:05 kernel: wlan0: Ethernet address: 00:0b:6b:34:58: Nov 10 19:32:05 kernel: 99 Nov 10 19:32:26 kernel: wlan1: Ethernet add Nov 10 19:32:26 kernel: ress: 00:0b:6b:34:58:99 -- http://www.voedselbankleiden.nl needs your help! http://martenvijn.nl http://bsd.wifisoft.org/nek/ http://opencommunitycamp.org OCC 2010 From info at martenvijn.nl Thu Nov 12 14:26:41 2009 From: info at martenvijn.nl (Marten Vijn) Date: Thu Nov 12 14:26:52 2009 Subject: 8.0-rc2 dropped hardsupport Message-ID: <1258035998.4826.1.camel@mvn-desktop> Support for the following devices seems not to be continued in 8.0 (and 7.2 and higher): - WRAP 1C - WRAP 2E (EOL) - ALIX 1C Both devices stopped booting as described in several postings and pr's. My question/suggestion to announce this in the >7.2 and 8.0 release notes. (or better to fix the issues) kind regards, Marten -- http://www.voedselbankleiden.nl Needs your help! http://martenvijn.nl http://bsd.wifisoft.org/nek/ The Network Event Kit http://opencommunitycamp.org OCC 2010 From smithi at nimnet.asn.au Thu Nov 12 14:29:19 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Nov 12 14:29:26 2009 Subject: SMART In-Reply-To: References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> <288A7D7F-C247-4493-8ED1-E67FFC3E0201@exscape.org> <20091112133221.00006b43@unknown> <4AFC166B.1040502@andric.com> Message-ID: <20091113011419.Y57967@sola.nimnet.asn.au> On Thu, 12 Nov 2009, Ivan Voras wrote: > Dimitry Andric wrote: > > On 2009-11-12 14:35, Ivan Voras wrote: > > > I've seen it. But I don't remember if they addressed the problem of > > > nonstandard interpretations of statistics? > > > > Note the statistics you quoted are "Vendor Specific SMART Attributes", > > so it is quite logical for different vendors to have different > > statistics. :) > > I see your point :) > > Though I would hope that a statistics like: > > 1 Raw_Read_Error_Rate 0x000f 087 083 006 Pre-fail Always > - 45398197 > > would have an equivalent across vendors :) I know, it's too much to ask :) True .. but all you really need to know is that as far as your disk vendor is concerned, your error rate is 87 (somethings), the worst it's ever been is 83 and if it were nearer 6 somethings, you should worry :) 9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 10155 Seagate says you're only 11% on the way to (mean) oblivion .. if you believe it should run 11.4 years. We had one 4GB IBM drive that did! cheers, Ian From kensmith at buffalo.edu Thu Nov 12 15:38:40 2009 From: kensmith at buffalo.edu (Ken Smith) Date: Thu Nov 12 15:39:16 2009 Subject: 8.0-RC3 Available Message-ID: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> The third and hopefully last of the Release Candidates for the FreeBSD 8.0 release cycle is now available. Unless something catastrophic comes up within the next couple of days we will begin the final builds for 8.0-RELEASE. There is one known issue with the igb(4) driver we are still deciding whether or not to fix as part of 8.0-RELEASE versus doing an Errata Notice for it some time after the release is out. It has been patched in head, and the SVN commit for it is r199192. If any of you are able to give that patch a try on a machine with the igb(4) NIC it would be appreciated. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is "about to become a stable branch" but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a "memory stick" image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. The DVD image includes the packages that will probably be available on the official release media but is subject to change between now and release. For sparc64 there is now a livefs cdrom, disc1 includes the documentation packages, and the DVD image has the set of packages that currently build for sparc64 (which is a sub-set of the set provided for amd64/i386). If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8_0. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, 8.0-RC1 or 8.0-RC2 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC3 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC3: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC3-amd64-bootonly.iso) = 641881caa82ea85c118bc15fff12fce6 MD5 (8.0-RC3-amd64-disc1.iso) = 854c273b89792cd0366d5399df1034eb MD5 (8.0-RC3-amd64-dvd1.iso) = 9bd1bb2507bc2a3037bc321bb2724bd6 MD5 (8.0-RC3-amd64-livefs.iso) = c5f427c8bf823e10a5348935cec2d7ee MD5 (8.0-RC3-amd64-memstick.img) = 6af9e213914a58a5779715ae5882bd25 MD5 (8.0-RC3-i386-bootonly.iso) = dfaec92ae358ab780d317aa66482ca9e MD5 (8.0-RC3-i386-disc1.iso) = 460f6cfddaebee6ae59a7d5f73695246 MD5 (8.0-RC3-i386-dvd1.iso) = 98d3f65f2444a8745f787df5ce9e1f0c MD5 (8.0-RC3-i386-livefs.iso) = 5184b7f6403d1d24991533bde0e580ff MD5 (8.0-RC3-i386-memstick.img) = 8774ef1d6bdf541e440f2f8ed22a2493 MD5 (8.0-RC3-ia64-bootonly.iso) = fd0af8f34937cf7fc78ea0063252afb7 MD5 (8.0-RC3-ia64-disc1.iso) = 96313c25e53fc333c258ed675007f3d7 MD5 (8.0-RC3-ia64-disc2.iso) = 235714607a2805c396ece829839405be MD5 (8.0-RC3-ia64-disc3.iso) = 53fca9243ccc788190ca58d24f363cbe MD5 (8.0-RC3-ia64-dvd1.iso) = 4e24736ab50bc2227c72dbeab6869266 MD5 (8.0-RC3-ia64-livefs.iso) = b6d76cf77ed714631bf714ff78b8e950 MD5 (8.0-RC3-pc98-bootonly.iso) = 137d17ec3830b6ae831b6fb48adf86e0 MD5 (8.0-RC3-pc98-disc1.iso) = 3624b1f7b3a659a7454718e38b9a1ee0 MD5 (8.0-RC3-pc98-livefs.iso) = 29ed3786b2df1c2e72e45d1187f3e788 MD5 (8.0-RC3-powerpc-bootonly.iso) = e7d8508639dee4aed5e52a24d6e27b69 MD5 (8.0-RC3-powerpc-disc1.iso) = 1016ae7753db153b7be0f5d167f595b9 MD5 (8.0-RC3-powerpc-disc2.iso) = aec2400454631cc2eaecb6f618bfecc8 MD5 (8.0-RC3-powerpc-disc3.iso) = fe36d621ad4b6347f8ade9800ccfab7b MD5 (8.0-RC3-sparc64-bootonly.iso) = c35ddcb4dd050c793d89973eba02df72 MD5 (8.0-RC3-sparc64-disc1.iso) = 0d3855603ac868609fb882c321555508 MD5 (8.0-RC3-sparc64-dvd1.iso) = 7a402ec8d17804bd6d16fad0969c9e52 MD5 (8.0-RC3-sparc64-livefs.iso) = 61c90ecce584c0c91f91e744f40a7d42 SHA256 (8.0-RC3-amd64-bootonly.iso) = fbf7c68cf81c300ec4e944ed6491f65d217168a85c1863c019cb41eec30cae94 SHA256 (8.0-RC3-amd64-disc1.iso) = 7e377f38cb6dc0ba1aa1fa13facf7e03f3cefad3d1490de797ed3a91680892e8 SHA256 (8.0-RC3-amd64-dvd1.iso) = fa4671d9b9b5b8208579d51cc2f72188a9537984ee28ba851236a52f32022597 SHA256 (8.0-RC3-amd64-livefs.iso) = c8c3728583b43e76d5e305b20fed578474adb5b14dbf2537b8ca9156b2d1c4cd SHA256 (8.0-RC3-amd64-memstick.img) = b8d90dbfca07160d9818bf6705b5dd99ba25fe1624cdda3f3f4919681d1b1af1 SHA256 (8.0-RC3-i386-bootonly.iso) = f514dbec335fbf72917b25c1e79f6bca4e9dd74e037f75ab30d810e7942ac2fc SHA256 (8.0-RC3-i386-disc1.iso) = 6b306af4a74df57d2c155891557878d747bac92a24c2b46947f89e7d9657addc SHA256 (8.0-RC3-i386-dvd1.iso) = 21794b11142eeb7eb56c8810b83dcd67230b0d26a0f0e5839866172d977a5626 SHA256 (8.0-RC3-i386-livefs.iso) = 3dfd45e0a5550913b29d19d989f19167159d1f926f1667d1622890a5f83be93b SHA256 (8.0-RC3-i386-memstick.img) = afc65bf14101ace1f069323678a8070ab84823bf191aeefa8fc9909d38e9306e SHA256 (8.0-RC3-ia64-bootonly.iso) = 1fefdd0b03c943162cbb66d507e11c3a2e541e97a0742471de49f17ae96b953c SHA256 (8.0-RC3-ia64-disc1.iso) = 67124c8101dd3fb06dbd3771c3eb18560207b42e46c331cc2ab02ba5284a72b7 SHA256 (8.0-RC3-ia64-disc2.iso) = 4eaa1125f98c5ed463f7577b9818dd57dbaee0bad01a1c7543ad4cc89c1770d0 SHA256 (8.0-RC3-ia64-disc3.iso) = c178a48004a12d6f178b478da146582742a88a27fcbf380029ae7fb3f6db6472 SHA256 (8.0-RC3-ia64-dvd1.iso) = d45a8e6ae622c1985d5b9c346c74f44884f3adba3c02d0b69bb58f19b359fa73 SHA256 (8.0-RC3-ia64-livefs.iso) = 9132340e15b75601017b0b57902fa48926e1d1a257f1f5149baa07c15e0dede8 SHA256 (8.0-RC3-pc98-bootonly.iso) = 42beee44af5859861718978a03de04e6a6fd0e63afec66a939830286fb73b22a SHA256 (8.0-RC3-pc98-disc1.iso) = 4b00447579349443d80082d1809b0d04688ea317a9bee3f551c13a35c82c549d SHA256 (8.0-RC3-pc98-livefs.iso) = 243306c98a9eade16d90994217fd89f0aba51cfd8399b1017754a3415f2e79e8 SHA256 (8.0-RC3-powerpc-bootonly.iso) = 4cfbcac5fc69bb10860ed2c511bcf175be730c2fd11e57ccd2c8c77322ea5172 SHA256 (8.0-RC3-powerpc-disc1.iso) = 6d7725d24c01d985590566eb168cde1e6d334a3cdc6bdc7a4508ea54c205c489 SHA256 (8.0-RC3-powerpc-disc2.iso) = ecfd22166dd411359d74a61c1724cfa747e4a7e9cb8b47776643795f6388942b SHA256 (8.0-RC3-powerpc-disc3.iso) = fc3c0c2823b36cc6530c7afdb73dbfa3cb1bf6a64a59fd4a55307e1e4d1541fe SHA256 (8.0-RC3-sparc64-bootonly.iso) = 44a641e1f3080112d6063f923d1e5d17f9d9eedd1004888aace77e08beca2fdf SHA256 (8.0-RC3-sparc64-disc1.iso) = e68eec5765f9313a9cbe4e94915b89d68caa4f4f65884be9e7b1d463862c17e3 SHA256 (8.0-RC3-sparc64-dvd1.iso) = e824cc316c520d29673c51e5ccf58aba9a79b17e7b61b67c1d13da7300911f7b SHA256 (8.0-RC3-sparc64-livefs.iso) = a4f0f8f02a9b1bad01088f5cb81a9a4d93ef6aad095afdd79cb5525b4a1e53b5 -- Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091112/94bbbc6a/attachment.pgp From lab at gta.com Thu Nov 12 15:48:37 2009 From: lab at gta.com (Larry Baird) Date: Thu Nov 12 15:48:44 2009 Subject: 8.0-rc2 dropped hardsupport In-Reply-To: <1091012.9283.79817@localhost> Message-ID: <20091112152154.91849.qmail@mailgate.gta.com> In article <1091012.9283.79817@localhost> you wrote: > Support for the following devices seems not to be continued in 8.0 (and > 7.2 and higher): > > - WRAP 1C > - WRAP 2E (EOL) > - ALIX 1C > > Both devices stopped booting as described in several postings and pr's. I have FreeBSD 8 running on WRAP and ALIX boards. LBA support for ALIX is broken in older versions of the BIOS. For LBA to work you need BIOS v0.99h. What problems are you seeing? Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From jhb at freebsd.org Thu Nov 12 15:54:22 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 12 15:54:29 2009 Subject: 8.0-rc2 dropped hardsupport In-Reply-To: <1258035998.4826.1.camel@mvn-desktop> References: <1258035998.4826.1.camel@mvn-desktop> Message-ID: <200911121035.17514.jhb@freebsd.org> On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote: > Support for the following devices seems not to be continued in 8.0 (and > 7.2 and higher): > > - WRAP 1C > - WRAP 2E (EOL) > - ALIX 1C > > Both devices stopped booting as described in several postings and pr's. What are these devices? Random model numbers generally aren't enough context for most people to figure out what you are asking. Are these embedded ARM boards, storage controllers, wireless NICs, etc.? -- John Baldwin From ivoras at freebsd.org Thu Nov 12 15:59:32 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 15:59:39 2009 Subject: 8.0-rc2 dropped hardsupport In-Reply-To: <200911121035.17514.jhb@freebsd.org> References: <1258035998.4826.1.camel@mvn-desktop> <200911121035.17514.jhb@freebsd.org> Message-ID: John Baldwin wrote: > On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote: >> Support for the following devices seems not to be continued in 8.0 (and >> 7.2 and higher): >> >> - WRAP 1C >> - WRAP 2E (EOL) >> - ALIX 1C >> >> Both devices stopped booting as described in several postings and pr's. > > What are these devices? Random model numbers generally aren't enough context > for most people to figure out what you are asking. Are these embedded ARM > boards, storage controllers, wireless NICs, etc.? Small (embedded) x86 boards: http://www.pcengines.ch/ From freebsd at jdc.parodius.com Thu Nov 12 16:01:30 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 12 16:01:37 2009 Subject: 8.0-rc2 dropped hardsupport In-Reply-To: <200911121035.17514.jhb@freebsd.org> References: <1258035998.4826.1.camel@mvn-desktop> <200911121035.17514.jhb@freebsd.org> Message-ID: <20091112160128.GA24144@icarus.home.lan> On Thu, Nov 12, 2009 at 10:35:17AM -0500, John Baldwin wrote: > On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote: > > Support for the following devices seems not to be continued in 8.0 (and > > 7.2 and higher): > > > > - WRAP 1C > > - WRAP 2E (EOL) > > - ALIX 1C > > > > Both devices stopped booting as described in several postings and pr's. > > What are these devices? Random model numbers generally aren't enough context > for most people to figure out what you are asking. Are these embedded ARM > boards, storage controllers, wireless NICs, etc.? The above are all PC Engines products. WRAP series: http://www.pcengines.ch/wrap.htm ALIX series: http://www.pcengines.ch/alix.htm -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ivoras at freebsd.org Thu Nov 12 16:05:11 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 16:05:18 2009 Subject: 8.0-rc2 dropped hardsupport In-Reply-To: <1258035998.4826.1.camel@mvn-desktop> References: <1258035998.4826.1.camel@mvn-desktop> Message-ID: Marten Vijn wrote: > Support for the following devices seems not to be continued in 8.0 (and > 7.2 and higher): > > - ALIX 1C For what it's worth, I've run the entire 7-STABLE and 8-CURRENT/STABLE development cycle kernels on a similarily equipped fit-pc with AMD Geode (I think it is LX800) without any issue at all. From mike at sentex.net Thu Nov 12 16:09:16 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 12 16:09:24 2009 Subject: 8.0-rc2 dropped hardsupport In-Reply-To: <20091112160128.GA24144@icarus.home.lan> References: <1258035998.4826.1.camel@mvn-desktop> <200911121035.17514.jhb@freebsd.org> <20091112160128.GA24144@icarus.home.lan> Message-ID: <200911121609.nACG9Eme037736@lava.sentex.ca> At 11:01 AM 11/12/2009, Jeremy Chadwick wrote: >On Thu, Nov 12, 2009 at 10:35:17AM -0500, John Baldwin wrote: > > On Thursday 12 November 2009 9:26:38 am Marten Vijn wrote: > > > Support for the following devices seems not to be continued in 8.0 (and > > > 7.2 and higher): > > > > > > - WRAP 1C > > > - WRAP 2E (EOL) > > > - ALIX 1C > > > > > > Both devices stopped booting as described in several postings and pr's. >WRAP series: http://www.pcengines.ch/wrap.htm >ALIX series: http://www.pcengines.ch/alix.htm > Not sure about the older WRAP boards, but the current Alix boxes work very well with RELENG_7 and RELENG_8. There is a patch however for RELENG_7 that never got MFC'd for some reason that I use as well. Phk ? ---Mike --- sys/i386/i386/geode.c 2007-09-18 05:19:44.000000000 -0400 +++ sys/i386/i386/geode.c.good 2008-09-12 17:13:18.000000000 -0400 @@ -25,7 +25,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/i386/i386/geode.c,v 1.10 2007/09/18 09:19:44 phk Exp $"); +__FBSDID("$FreeBSD: src/sys/i386/i386/geode.c,v 1.11 2008/02/10 19:14:42 phk Exp $"); #include #include @@ -40,41 +40,50 @@ #include static struct bios_oem bios_soekris = { - { 0xf0000, 0xf1000 }, - { - { "Soekris", 0, 8 }, /* Soekris Engineering. */ - { "net4", 0, 8 }, /* net45xx */ - { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ - { NULL, 0, 0 }, - } + { 0xf0000, 0xf1000 }, + { + { "Soekris", 0, 8 }, /* Soekris Engineering. */ + { "net4", 0, 8 }, /* net45xx */ + { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ + { NULL, 0, 0 }, + } }; static struct bios_oem bios_soekris_55 = { - { 0xf0000, 0xf1000 }, - { - { "Soekris", 0, 8 }, /* Soekris Engineering. */ - { "net5", 0, 8 }, /* net5xxx */ - { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ - { NULL, 0, 0 }, - } + { 0xf0000, 0xf1000 }, + { + { "Soekris", 0, 8 }, /* Soekris Engineering. */ + { "net5", 0, 8 }, /* net5xxx */ + { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ + { NULL, 0, 0 }, + } }; static struct bios_oem bios_pcengines = { - { 0xf9000, 0xfa000 }, - { - { "PC Engines WRAP", 0, 28 }, /* PC Engines WRAP.1C v1.03 */ - { "tinyBIOS", 0, 28 }, /* tinyBIOS V1.4a (C)1997-2003 */ - { NULL, 0, 0 }, - } + { 0xf9000, 0xfa000 }, + { + { "PC Engines WRAP", 0, 28 }, /* PC Engines WRAP.1C v1.03 */ + { "tinyBIOS", 0, 28 }, /* tinyBIOS V1.4a (C)1997-2003 */ + { NULL, 0, 0 }, + } +}; + +static struct bios_oem bios_pcengines_55 = { + { 0xf9000, 0xfa000 }, + { + { "PC Engines ALIX", 0, 28 }, /* PC Engines ALIX */ + { "tinyBIOS", 0, 28 }, /* tinyBIOS V1.4a (C)1997-2005 */ + { NULL, 0, 0 }, + } }; static struct bios_oem bios_advantech = { - { 0xfe000, 0xff000 }, - { - { "**** PCM-582", 5, 33 }, /* PCM-5823 BIOS V1.12 ... */ - { "GXm-Cx5530", -11, 35 }, /* 06/07/2002-GXm-Cx5530... */ - { NULL, 0, 0 }, - } + { 0xfe000, 0xff000 }, + { + { "**** PCM-582", 5, 33 }, /* PCM-5823 BIOS V1.12 ... */ + { "GXm-Cx5530", -11, 35 }, /* 06/07/2002-GXm-Cx5530... */ + { NULL, 0, 0 }, + } }; static unsigned cba; @@ -117,6 +126,11 @@ } a = rdmsr(0x5140000c); + if (bit >= 16) { + a += 0x80; + bit -= 16; + } + if (onoff) outl(a, 1 << bit); else @@ -256,11 +270,13 @@ * by the bios, see p161 in data sheet. */ cba = pci_read_config(self, 0x64, 4); - printf("Geode CBA@ 0x%x\n", cba); + if (bootverbose) + printf("Geode CBA@ 0x%x\n", cba); geode_counter = cba + 0x08; outl(cba + 0x0d, 2); - printf("Geode rev: %02x %02x\n", - inb(cba + 0x3c), inb(cba + 0x3d)); + if (bootverbose) + printf("Geode rev: %02x %02x\n", + inb(cba + 0x3c), inb(cba + 0x3d)); tc_init(&geode_timecounter); EVENTHANDLER_REGISTER(watchdog_list, geode_watchdog, NULL, 0); @@ -270,13 +286,14 @@ case 0x0510100b: gpio = pci_read_config(self, PCIR_BAR(0), 4); gpio &= ~0x1f; - printf("Geode GPIO@ = %x\n", gpio); - if ( bios_oem_strings(&bios_soekris, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { + if (bootverbose) + printf("Geode GPIO@ = %x\n", gpio); + if (bios_oem_strings(&bios_soekris, + bios_oem, sizeof bios_oem) > 0 ) { led1b = 20; led1 = led_create(led_func, &led1b, "error"); - } else if ( bios_oem_strings(&bios_pcengines, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { + } else if (bios_oem_strings(&bios_pcengines, + bios_oem, sizeof bios_oem) > 0 ) { led1b = -2; led2b = -3; led3b = -18; @@ -289,27 +306,41 @@ */ led_func(&led1b, 1); } - if ( strlen(bios_oem) ) + if (*bios_oem) printf("Geode %s\n", bios_oem); break; case 0x01011078: - if ( bios_oem_strings(&bios_advantech, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { + if (bios_oem_strings(&bios_advantech, + bios_oem, sizeof bios_oem) > 0 ) { printf("Geode %s\n", bios_oem); EVENTHANDLER_REGISTER(watchdog_list, advantech_watchdog, NULL, 0); } break; case 0x20801022: - if ( bios_oem_strings(&bios_soekris_55, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { - printf("Geode LX: %s\n", bios_oem); + if (bios_oem_strings(&bios_soekris_55, + bios_oem, sizeof bios_oem) > 0 ) { led1b = 6; led1 = led_create(cs5536_led_func, &led1b, "error"); + } else if (bios_oem_strings(&bios_pcengines_55, + bios_oem, sizeof bios_oem) > 0 ) { + led1b = -6; + led2b = -25; + led3b = -27; + led1 = led_create(cs5536_led_func, &led1b, "led1"); + led2 = led_create(cs5536_led_func, &led2b, "led2"); + led3 = led_create(cs5536_led_func, &led3b, "led3"); + /* + * Turn on first LED so we don't make + * people think their box just died. + */ + cs5536_led_func(&led1b, 1); } - printf("MFGPT bar: %jx\n", rdmsr(0x5140000d)); - EVENTHANDLER_REGISTER(watchdog_list, cs5536_watchdog, - NULL, 0); + if (*bios_oem) + printf("Geode LX: %s\n", bios_oem); + if (bootverbose) + printf("MFGPT bar: %jx\n", rdmsr(0x5140000d)); + EVENTHANDLER_REGISTER(watchdog_list, cs5536_watchdog, NULL, 0); break; } return (ENXIO); ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From mad at madpilot.net Thu Nov 12 16:33:20 2009 From: mad at madpilot.net (Guido Falsi) Date: Thu Nov 12 16:33:27 2009 Subject: ciss(4) not seeing multiple LUNs Message-ID: <20091112163315.GB11200@megatron.madpilot.net> Hello, I'm having a strange problem with HP hardware and the ciss(4) driver. I have an HP DL160 G6 server with FreeBSD 8 (cvsupped from RELENG_8 yesterday) with a Smart Array P212 SAS controller. There is an HP Storageworks 1/8 G2 autoloader (dmesg from the machine attached). The problem is I only get the sa0 device from the tape drive on LUN 0 of the device, the ch0 device which should be at LUN 1 is not detected. Camcontrol gives this output: # camcontrol devlist -v scbus0 on ciss0 bus 0: scbus1 on ciss0 bus 32: at scbus1 target 4 lun 0 (sa0,pass0) scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) # camcontrol reportluns 1:4 2 LUNs found 0 1 If I try to force a rescan of device 4:1:1 (or any 4:1:x for that matter) it will happily report a device, but it will be the same device it sees on LUN 0. I tried the syscontrols reported in ciss(4) without any change. I could not find much ducumentation about this on HP site. The controller's documentation says it "supports" the autoloader, so it should be able to see it. Maybe I need to enable something in the contorller but I got no documetnation about that. Does someone has got an idea? Is this a problem with the ciss driver? Thanks in advance for any help! -- Guido Falsi From mad at madpilot.net Thu Nov 12 16:36:41 2009 From: mad at madpilot.net (Guido Falsi) Date: Thu Nov 12 16:36:49 2009 Subject: ciss(4) not seeing multiple LUNs In-Reply-To: <20091112163315.GB11200@megatron.madpilot.net> References: <20091112163315.GB11200@megatron.madpilot.net> Message-ID: <20091112163636.GC11200@megatron.madpilot.net> On Thu, Nov 12, 2009 at 05:33:15PM +0100, Guido Falsi wrote: > Hello, > > I have an HP DL160 G6 server with FreeBSD 8 (cvsupped from RELENG_8 > yesterday) with a Smart Array P212 SAS controller. There is an HP > Storageworks 1/8 G2 autoloader (dmesg from the machine attached). Forgot the attachment, sorry. Here it comes. -- Guido Falsi -------------- next part -------------- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RC2 #6: Thu Nov 12 11:57:04 CET 2009 root@xxx.xxx.it:/usr/obj/usr/src/sys/UXIFI04 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.08-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4095668224 (3905 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 ioapic0: Changing APIC ID to 1 ioapic1: Changing APIC ID to 3 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci8: on pcib1 pcib2: at device 3.0 on pci0 pci7: on pcib2 ciss0: port 0xe800-0xe8ff mem 0xfb800000-0xfbbfffff,0xfbeff000-0xfbefffff irq 24 at device 0.0 on pci7 ciss0: PERFORMANT Transport ciss0: [ITHREAD] pcib3: at device 7.0 on pci0 pci6: on pcib3 pcib4: at device 9.0 on pci0 pci5: on pcib4 igb0: port 0xd880-0xd89f mem 0xfb760000-0xfb77ffff,0xfb740000-0xfb75ffff,0xfb7b8000-0xfb7bbfff irq 32 at device 0.0 on pci5 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:26:55:80:53:fe igb1: port 0xdc00-0xdc1f mem 0xfb7e0000-0xfb7fffff,0xfb7c0000-0xfb7dffff,0xfb7bc000-0xfb7bffff irq 42 at device 0.1 on pci5 igb1: Using MSIX interrupts with 3 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:26:55:80:53:ff pcib5: at device 10.0 on pci0 pci4: on pcib5 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) uhci0: port 0xb800-0xb81f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2400 usbus0: on uhci0 ehci0: mem 0xfa7f8000-0xfa7f83ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 pcib6: irq 16 at device 28.0 on pci0 pci3: on pcib6 pcib7: irq 16 at device 28.4 on pci0 pci2: on pcib7 vgapci0: mem 0xf8000000-0xf8ffffff,0xfb6fc000-0xfb6fffff,0xfa800000-0xfaffffff irq 16 at device 0.0 on pci2 uhci1: port 0xb880-0xb89f irq 23 at device 29.0 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2400 usbus2: on uhci1 uhci2: port 0xbc00-0xbc1f irq 19 at device 29.1 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2400 usbus3: on uhci2 uhci3: port 0xc000-0xc01f irq 18 at device 29.2 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2400 usbus4: on uhci3 ehci1: mem 0xfa7fa000-0xfa7fa3ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pcib8: at device 30.0 on pci0 pci1: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xc880-0xc887,0xc800-0xc803,0xc480-0xc487,0xc400-0xc403,0xc080-0xc09f mem 0xfa7fc000-0xfa7fc7ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 11, should be 10 20090521 tbutils-275 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 13 ZFS storage pool version 13 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x110 offMax=0x238 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master SATA300 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ad6: 152627MB at ata3-master SATA300 uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub5: 6 ports with 6 removable, self powered ugen0.2: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates ID=0 ugen3.2: at usbus3 ums1: on usbus3 ums1: 3 buttons and [XYZ] coordinates ID=0 (probe19:ciss0:32:4:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe19:ciss0:32:4:0): CAM Status: SCSI Status Error (probe19:ciss0:32:4:0): SCSI Status: Check Condition (probe19:ciss0:32:4:0): NOT READY asc:3a,0 (probe19:ciss0:32:4:0): Medium not present (probe19:ciss0:32:4:0): Unretryable error sa0 at ciss0 bus 32 target 4 lun 0 sa0: Removable Sequential Access SCSI-5 device sa0: 135.168MB/s transfers sa0: Command Queueing enabled SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Trying to mount root from zfs:tank ugen3.3: at usbus3 ukbd1: on usbus3 kbd3 at ukbd1 uhid0: on usbus3 igb0: link state changed to UP From matthew.fleming at isilon.com Thu Nov 12 16:42:29 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Thu Nov 12 16:42:36 2009 Subject: 8.0RC2 "top" statistics seem broken In-Reply-To: <20091112071618.GB81250@rambler-co.ru> References: <20091112071618.GB81250@rambler-co.ru> Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E0338FEB8@seaxch09.desktop.isilon.com> > > [snip] > > > > Load average and %CPU user are right, as are other global statistics. > > The load is produced by the "7z" process (archivers/p7zip) which > > compresses some data in two threads but is credited with 0% CPU, though > > its runtime is correct (increments every second as it should in a > > CPU-bound process). It doesn't help if I expand / show individual > threads. > > I believe this is related to multithreaded processes only. I saw this for > intr kernel process. Singlethread processes eat CPU slightly less than > on 7.2, however, I can not say is it statistic errors or real speedup. > I saw the issue on SMP/ULE only and can not say anything about UP and > 4BSD scheduler. Check out r197652 on stable/7. I had a similar problem where top was showing 0% for a CPU hog, but since I was unable to replicate it on CURRENT (and the ULE accounting code is different between releases) I only submitted for stable/7. I think the patch will be easy to apply by hand, though, to test it. Thanks, matthew From info at martenvijn.nl Thu Nov 12 17:27:37 2009 From: info at martenvijn.nl (Marten Vijn) Date: Thu Nov 12 17:27:44 2009 Subject: 8.0-rc2 dropped hardwaresupport In-Reply-To: <20091112152154.91849.qmail@mailgate.gta.com> References: <20091112152154.91849.qmail@mailgate.gta.com> Message-ID: <1258046854.4826.160.camel@mvn-desktop> On Thu, 2009-11-12 at 15:21 +0000, Larry Baird wrote: > In article <1091012.9283.79817@localhost> you wrote: > > Support for the following devices seems not to be continued in 8.0 (and > > 7.2 and higher): > > > > - WRAP 1C > > - WRAP 2E (EOL) > > - ALIX 1C > > > > Both devices stopped booting as described in several postings and pr's. > I have FreeBSD 8 running on WRAP and ALIX boards. LBA support for ALIX is > broken in older versions of the BIOS. For LBA to work you need BIOS > v0.99h. What problems are you seeing? > > Larry > I did some more testing, and I made an error on the ALIX 1C since it does boot but it hangs on devd.... but for WRAP 1C and 2E: PC Engines WRAP.2B/2C v1.11 640 KB Base Memory 130048 KB Extended Memory 01F0 Master 044A CF CARD 2GB Phys C/H/S 3909/16/63 Log C/H/S 977/64/63 1 FreeBSD 2 FreeBSD F6 PXE Boot: 1 ######## Here it ends.... Would you recommend to downgrade the bios? I have version 1.11 on all boards. thanks Marten -- http://www.voedselbankleiden.nl needs your help! http://martenvijn.nl http://bsd.wifisoft.org/nek/ http://opencommunitycamp.org OCC 2010 From freebsd at jdc.parodius.com Thu Nov 12 17:44:31 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 12 17:44:38 2009 Subject: SMART In-Reply-To: References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> Message-ID: <20091112174428.GA24213@icarus.home.lan> On Thu, Nov 12, 2009 at 01:25:12PM +0100, Ivan Voras wrote: > Jeremy Chadwick wrote: > > >I can teach you how to decode/read SMART statistics correctly. > > > > Actually, it would be good if you taught more than him :) > > I've always wondered how important are each of the dozen or so > statistics and what indicates what... I started a write-up but after writing about 300 lines realised that if I continued the details would eventually be lost in the Sea of Information Chaos that is a mailing list. :-) I've gone over how to read SMART data 3 separate times in the past 2 months (at work, on a public forum, and in private mail), so this would be the 4th... I'll work on writing an actual HTML document to put up on my web site and will respond with the URL once I finish it. Sorry for the "yeah sure I can help you read this data" response followed by what will probably be labelled as an excuse by some. Admittedly reading the output is pretty simple, but "getting familiar" with what the output looks like (on a per-vendor basis) takes exposure to all sorts of drives, ditto with F/W bugs and so on. In general though, don't let anyone tell you SMART is worthless. The "overall health assessment" status is generally worthless, but the per-attribute data is of great use. Don't let anyone tell you the weighted/adjusted values (VALUE/WORST/THRESH) are useless either; in some cases they're all you can safely rely on. Don't damn SMART when it's actually the manufacturers which need to be spanked for setting such unreasonable health failure thresholds. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From lab at gta.com Thu Nov 12 18:07:45 2009 From: lab at gta.com (Larry Baird) Date: Thu Nov 12 18:07:52 2009 Subject: 8.0-rc2 dropped hardwaresupport In-Reply-To: <1258046854.4826.160.camel@mvn-desktop> References: <20091112152154.91849.qmail@mailgate.gta.com> <1258046854.4826.160.camel@mvn-desktop> Message-ID: <20091112180743.GA23798@gta.com> Marten, > I did some more testing, and I made an error on the ALIX 1C since it > does boot but it hangs on devd.... > but for WRAP 1C and 2E: > > PC Engines WRAP.2B/2C v1.11 > 640 KB Base Memory > 130048 KB Extended Memory > > 01F0 Master 044A CF CARD 2GB > Phys C/H/S 3909/16/63 Log C/H/S 977/64/63 > > 1 FreeBSD > 2 FreeBSD > > F6 PXE > Boot: 1 ######## > > Here it ends.... > > Would you recommend to downgrade the bios? I have version 1.11 on all > boards. The 0.99h BIOS is for ALIX boards. I am running v1.11 on my WRAP boards. PC Engines WRAP.1C/1D/1E v1.11 640 KB Base Memory 130048 KB Extended Memory Looking at your geometry, I would recommend verifing that the BIOS is set for LBA mode (not CHS). If you change mode, you will probably need to reinstall FreeBSD. Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From is at rambler-co.ru Thu Nov 12 19:50:23 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Thu Nov 12 19:50:31 2009 Subject: 8.0RC2 "top" statistics seem broken In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E0338FEB8@seaxch09.desktop.isilon.com> References: <20091112071618.GB81250@rambler-co.ru> <06D5F9F6F655AD4C92E28B662F7F853E0338FEB8@seaxch09.desktop.isilon.com> Message-ID: <20091112195020.GC40464@rambler-co.ru> On Thu, Nov 12, 2009 at 08:42:28AM -0800, Matthew Fleming wrote: > > > [snip] > > > > > > Load average and %CPU user are right, as are other global > statistics. > > > The load is produced by the "7z" process (archivers/p7zip) which > > > compresses some data in two threads but is credited with 0% CPU, > though > > > its runtime is correct (increments every second as it should in a > > > CPU-bound process). It doesn't help if I expand / show individual > > threads. > > > > I believe this is related to multithreaded processes only. I saw this > for > > intr kernel process. Singlethread processes eat CPU slightly less than > > on 7.2, however, I can not say is it statistic errors or real speedup. > > I saw the issue on SMP/ULE only and can not say anything about UP and > > 4BSD scheduler. > > Check out r197652 on stable/7. I had a similar problem where top was > showing 0% for a CPU hog, but since I was unable to replicate it on > CURRENT (and the ULE accounting code is different between releases) I > only submitted for stable/7. I think the patch will be easy to apply by > hand, though, to test it. Thank you very much. I have applied your patch and it fixes the bug: CPU 0: 22.0% user, 0.0% nice, 4.9% system, 0.0% interrupt, 73.2% idle CPU 1: 1.2% user, 0.0% nice, 1.2% system, 4.9% interrupt, 92.7% idle PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 2 171 ki31 0K 32K CPU0 0 12:11 165.77% idle 1338 nobody 1 44 -10 439M 433M kqread 0 0:24 14.45% nginx 1339 nobody 1 44 -10 439M 433M kqread 0 0:23 12.89% nginx 12 root 15 -60 - 0K 240K WAIT 0 0:09 4.39% intr CPU 0: 16.2% user, 0.0% nice, 8.5% system, 0.8% interrupt, 74.5% idle CPU 1: 1.2% user, 0.0% nice, 1.9% system, 4.2% interrupt, 92.7% idle PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 32K RUN 1 6:39 88.96% {idle: cpu1} 11 root 171 ki31 0K 32K RUN 0 6:11 77.59% {idle: cpu0} 1338 nobody 44 -10 439M 433M CPU0 0 0:27 14.45% nginx 1339 nobody 44 -10 439M 433M RUN 1 0:26 14.26% nginx 12 root -68 - 0K 240K WAIT 1 0:09 4.69% {irq19: bge0} The patch against 8.0-PREREALSE is attached. -- Igor Sysoev http://sysoev.ru/en/ -------------- next part -------------- --- sys/kern/sched_ule.c 2009-11-02 09:25:28.000000000 +0300 +++ sys/kern/sched_ule.c 2009-11-12 21:53:45.000000000 +0300 @@ -103,6 +103,7 @@ u_int ts_slptime; /* Number of ticks we vol. slept */ u_int ts_runtime; /* Number of ticks we were running */ int ts_ltick; /* Last tick that we were running on */ + int ts_incrtick; /* Last tick that we incremented on */ int ts_ftick; /* First tick that we were running on */ int ts_ticks; /* Tick count */ #ifdef KTR @@ -1991,6 +1992,7 @@ */ ts2->ts_ticks = ts->ts_ticks; ts2->ts_ltick = ts->ts_ltick; + ts2->ts_incrtick = ts->ts_incrtick; ts2->ts_ftick = ts->ts_ftick; child->td_user_pri = td->td_user_pri; child->td_base_user_pri = td->td_base_user_pri; @@ -2182,11 +2184,12 @@ * Ticks is updated asynchronously on a single cpu. Check here to * avoid incrementing ts_ticks multiple times in a single tick. */ - if (ts->ts_ltick == ticks) + if (ts->ts_incrtick == ticks) return; /* Adjust ticks for pctcpu */ ts->ts_ticks += 1 << SCHED_TICK_SHIFT; ts->ts_ltick = ticks; + ts->ts_incrtick = ticks; /* * Update if we've exceeded our desired tick threshhold by over one * second. From royce at alaska.net Thu Nov 12 20:01:13 2009 From: royce at alaska.net (Royce Williams) Date: Thu Nov 12 20:01:22 2009 Subject: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R) Message-ID: <4AFC63B0.5020707@alaska.net> We have servers with dual 82573 NICs that work well during low-throughput activity, but during high-volume activity, they pause shortly after transfers start and do not recover. Other sessions to the system are not affected. These systems are being repurposed, jumping from 6.3 to 7.2. The same system and its kin do not exhibit the symptom under 6.3-RELEASE-p13. The symptoms appear under freebsd-updated 7.2-RELEASE GENERIC kernel with no tuning. Previously, we've been using DCGDIS.EXE (from Jack Vogel) for this symptom. The first system to be repurposed accepts DCGDIS with 'Updated' and subsequent 'update not needed', with no relief. Notably, there are no watchdog timeout errors - unlike our various Supermicro models still running FreeBSD 6.x. All of our other 7.x Supermicro flavors had already received the flash update and haven't show the symptom. Details follow. Kernel: rand# uname -a FreeBSD rand.acsalaska.net 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 sysctls: rand# sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x020000 dev.em.0.%parent: pci13 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x020000 dev.em.1.%parent: pci14 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 kenv: rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' smbios.bios.reldate="03/05/2008" smbios.bios.vendor="Phoenix Technologies LTD" smbios.bios.version="6.00" smbios.chassis.maker="Supermicro" smbios.planar.maker="Supermicro" smbios.planar.product="PDSMi " smbios.planar.version="PCB Version" smbios.system.maker="Supermicro" smbios.system.product="PDSMi" The system is not yet production, so I can invasively abuse it if needed. The other systems are in production under 6.3-RELEASE-p13 and can also be inspected. Any pointers appreciated. Royce From freebsd at jdc.parodius.com Thu Nov 12 20:47:37 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 12 20:47:44 2009 Subject: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R) In-Reply-To: <4AFC63B0.5020707@alaska.net> References: <4AFC63B0.5020707@alaska.net> Message-ID: <20091112204736.GA29095@icarus.home.lan> On Thu, Nov 12, 2009 at 10:36:16AM -0900, Royce Williams wrote: > We have servers with dual 82573 NICs that work well during low-throughput activity, but during high-volume activity, they pause shortly after transfers start and do not recover. Other sessions to the system are not affected. Please define "low-throughput" and "high-volume" if you could; it might help folks determine where the threshold is for problems. > These systems are being repurposed, jumping from 6.3 to 7.2. The same system and its kin do not exhibit the symptom under 6.3-RELEASE-p13. The symptoms appear under freebsd-updated 7.2-RELEASE GENERIC kernel with no tuning. > > Previously, we've been using DCGDIS.EXE (from Jack Vogel) for this symptom. The first system to be repurposed accepts DCGDIS with 'Updated' and subsequent 'update not needed', with no relief. > > Notably, there are no watchdog timeout errors - unlike our various Supermicro models still running FreeBSD 6.x. All of our other 7.x Supermicro flavors had already received the flash update and haven't show the symptom. > > Details follow. > > Kernel: > > rand# uname -a > FreeBSD rand.acsalaska.net 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 12:21:39 UTC 2009 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 > > sysctls: > > rand# sysctl dev.em > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x020000 > dev.em.0.%parent: pci13 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=0 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x020000 > dev.em.1.%parent: pci14 > dev.em.1.debug: -1 > dev.em.1.stats: -1 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 100 > > kenv: > > rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' > smbios.bios.reldate="03/05/2008" > smbios.bios.vendor="Phoenix Technologies LTD" > smbios.bios.version="6.00" > smbios.chassis.maker="Supermicro" > smbios.planar.maker="Supermicro" > smbios.planar.product="PDSMi " > smbios.planar.version="PCB Version" > smbios.system.maker="Supermicro" > smbios.system.product="PDSMi" > > > The system is not yet production, so I can invasively abuse it if needed. The other systems are in production under 6.3-RELEASE-p13 and can also be inspected. > > Any pointers appreciated. > > Royce For what it's worth as a comparison base: We use the following Supermicro SuperServers, and can confirm that no such issues occur for us using RELENG_6 nor RELENG_7 on the following hardware: Supermicro SuperServer 5015B-MTB - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L The 5015B-MTB system presently runs RELENG_8 -- no issues there either. Relevant server configuration and network setup details: - All machines use pf(4). - All emX devices are configured for autoneg. - All emX devices use RXCSUM, TXCSUM, and TSO4. - We do not use polling. - All machines use both NICs simultaneously at all times. - All machines connected to an HP ProCurve 2626 switch (100mbit, full-duplex ports, all autoneg). - We do not use Jumbo frames. - No add-in cards (PCI, PCI-X, nor PCIe) are used in the systems. - All of the systems had DCGDIS.EXE run on them; no EEPROM settings were changed, indicating the from-the-Intel-factory MANC register in question was set properly. Relevant throughput details per box: - em0 pushes ~600-1000kbit/sec at all times. - em1 pushes ~100-200kbit/sec at all times. - During nightly maintenance (backups), em1 pushes ~2-3mbit/sec for a variable amount of time. - For a full level 0 backup (which I've done numerous times), em1 pushes 60-70mbit/sec without issues. I've compared your sysctl dev.em output to that of our 5015M-T+B systems (which use the PDSMi+, not the PDSMi, but whatever), and ours is 100% identical. All of our 5015M-T+B systems are using BIOS 1.3, and the 5015B-MTB system is using BIOS 1.30. If you'd like, I can provide the exact BIOS settings we use on the machines in question; they do deviate from the factory defaults a slight bit, but none of the adjustments are "tweaks" for performance or otherwise (just disabling things which we don't use, etc.). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jfvogel at gmail.com Thu Nov 12 20:52:25 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Nov 12 20:52:32 2009 Subject: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R) In-Reply-To: <20091112204736.GA29095@icarus.home.lan> References: <4AFC63B0.5020707@alaska.net> <20091112204736.GA29095@icarus.home.lan> Message-ID: <2a41acea0911121252y81f365fo2982e43e3efdba4d@mail.gmail.com> It is critically important on these systems that you get the latest BIOS on them, so maybe that's the difference between you two. I am going to be putting out a new em driver to CURRENT soon, it might be an option to try that as well, it sounds like a hang, management/os race in the driver is a possibility. Jack On Thu, Nov 12, 2009 at 12:47 PM, Jeremy Chadwick wrote: > On Thu, Nov 12, 2009 at 10:36:16AM -0900, Royce Williams wrote: > > We have servers with dual 82573 NICs that work well during low-throughput > activity, but during high-volume activity, they pause shortly after > transfers start and do not recover. Other sessions to the system are not > affected. > > Please define "low-throughput" and "high-volume" if you could; it might > help folks determine where the threshold is for problems. > > > These systems are being repurposed, jumping from 6.3 to 7.2. The same > system and its kin do not exhibit the symptom under 6.3-RELEASE-p13. The > symptoms appear under freebsd-updated 7.2-RELEASE GENERIC kernel with no > tuning. > > > > Previously, we've been using DCGDIS.EXE (from Jack Vogel) for this > symptom. The first system to be repurposed accepts DCGDIS with 'Updated' > and subsequent 'update not needed', with no relief. > > > > Notably, there are no watchdog timeout errors - unlike our various > Supermicro models still running FreeBSD 6.x. All of our other 7.x > Supermicro flavors had already received the flash update and haven't show > the symptom. > > > > Details follow. > > > > Kernel: > > > > rand# uname -a > > FreeBSD rand.acsalaska.net 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri > Oct 2 12:21:39 UTC 2009 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > i386 > > > > sysctls: > > > > rand# sysctl dev.em > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 > > dev.em.0.%driver: em > > dev.em.0.%location: slot=0 function=0 > > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 > subdevice=0x108c class=0x020000 > > dev.em.0.%parent: pci13 > > dev.em.0.debug: -1 > > dev.em.0.stats: -1 > > dev.em.0.rx_int_delay: 0 > > dev.em.0.tx_int_delay: 66 > > dev.em.0.rx_abs_int_delay: 66 > > dev.em.0.tx_abs_int_delay: 66 > > dev.em.0.rx_processing_limit: 100 > > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 > > dev.em.1.%driver: em > > dev.em.1.%location: slot=0 function=0 > > dev.em.1.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 > subdevice=0x108c class=0x020000 > > dev.em.1.%parent: pci14 > > dev.em.1.debug: -1 > > dev.em.1.stats: -1 > > dev.em.1.rx_int_delay: 0 > > dev.em.1.tx_int_delay: 66 > > dev.em.1.rx_abs_int_delay: 66 > > dev.em.1.tx_abs_int_delay: 66 > > dev.em.1.rx_processing_limit: 100 > > > > kenv: > > > > rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' > > smbios.bios.reldate="03/05/2008" > > smbios.bios.vendor="Phoenix Technologies LTD" > > smbios.bios.version="6.00" > > smbios.chassis.maker="Supermicro" > > smbios.planar.maker="Supermicro" > > smbios.planar.product="PDSMi " > > smbios.planar.version="PCB Version" > > smbios.system.maker="Supermicro" > > smbios.system.product="PDSMi" > > > > > > The system is not yet production, so I can invasively abuse it if needed. > The other systems are in production under 6.3-RELEASE-p13 and can also be > inspected. > > > > Any pointers appreciated. > > > > Royce > > For what it's worth as a comparison base: > > We use the following Supermicro SuperServers, and can confirm that no > such issues occur for us using RELENG_6 nor RELENG_7 on the following > hardware: > > Supermicro SuperServer 5015B-MTB - amd64 - Intel 82573V + Intel 82573L > Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L > Supermicro SuperServer 5015M-T+B - amd64 - Intel 82573V + Intel 82573L > Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L > Supermicro SuperServer 5015M-T+B - i386 - Intel 82573V + Intel 82573L > > The 5015B-MTB system presently runs RELENG_8 -- no issues there either. > > Relevant server configuration and network setup details: > > - All machines use pf(4). > - All emX devices are configured for autoneg. > - All emX devices use RXCSUM, TXCSUM, and TSO4. > - We do not use polling. > - All machines use both NICs simultaneously at all times. > - All machines connected to an HP ProCurve 2626 switch (100mbit, > full-duplex ports, all autoneg). > - We do not use Jumbo frames. > - No add-in cards (PCI, PCI-X, nor PCIe) are used in the systems. > - All of the systems had DCGDIS.EXE run on them; no EEPROM settings > were changed, indicating the from-the-Intel-factory MANC register > in question was set properly. > > Relevant throughput details per box: > > - em0 pushes ~600-1000kbit/sec at all times. > - em1 pushes ~100-200kbit/sec at all times. > - During nightly maintenance (backups), em1 pushes ~2-3mbit/sec > for a variable amount of time. > - For a full level 0 backup (which I've done numerous times), em1 > pushes 60-70mbit/sec without issues. > > I've compared your sysctl dev.em output to that of our 5015M-T+B systems > (which use the PDSMi+, not the PDSMi, but whatever), and ours is 100% > identical. > > All of our 5015M-T+B systems are using BIOS 1.3, and the 5015B-MTB > system is using BIOS 1.30. > > If you'd like, I can provide the exact BIOS settings we use on the > machines in question; they do deviate from the factory defaults a slight > bit, but none of the adjustments are "tweaks" for performance or > otherwise (just disabling things which we don't use, etc.). > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From zbeeble at gmail.com Thu Nov 12 21:18:13 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Thu Nov 12 21:18:20 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 Message-ID: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> I have a dell 1950 here on the floor. Since "1950" seems to refer to a lot of things with a lot of configurations, I'm going to attempt to narrow that down a bit. It's got 2x 2.33Ghz dual core pentiums (stepping 06-0F-6 according to the bios) in it and it has an SAS RAID card that FreeBSD recognises. I've upgraded the BIOS to 2.6.1. It has two SAS 70G drives in a RAID 1 configuration and it has a DVD (although it will only boot from CDs). If it helps, it's between 2 and 3 years old, I think. If I allow the machine to boot normally, it stopps after checking the floppy (there is no floppy) with the following message: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 If I boot the machine without ACPI, it seems to stop at the same place (stopping after having checked the ata controller, which checks right before the floppy) If I boot the machine verbose, I get no more information --- it stopps at the same place. I have tried this (so far) with 7.2-R and 7.1-R. Both do the same thing. From amvandemore at gmail.com Thu Nov 12 21:27:54 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Thu Nov 12 21:28:01 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> Message-ID: <6201873e0911121327x8b5a16k86c5018582785396@mail.gmail.com> On Thu, Nov 12, 2009 at 2:46 PM, Zaphod Beeblebrox wrote: > I have a dell 1950 here on the floor. Since "1950" seems to refer to a lot > of things with a lot of configurations, I'm going to attempt to narrow that > down a bit. > > It's got 2x 2.33Ghz dual core pentiums (stepping 06-0F-6 according to the > bios) in it and it has an SAS RAID card that FreeBSD recognises. I've > upgraded the BIOS to 2.6.1. It has two SAS 70G drives in a RAID 1 > configuration and it has a DVD (although it will only boot from CDs). > > If it helps, it's between 2 and 3 years old, I think. > > If I allow the machine to boot normally, it stopps after checking the > floppy > (there is no floppy) with the following message: > > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > > If I boot the machine without ACPI, it seems to stop at the same place > (stopping after having checked the ata controller, which checks right > before > the floppy) > > If I boot the machine verbose, I get no more information --- it stopps at > the same place. > > I have tried this (so far) with 7.2-R and 7.1-R. Both do the same thing. > > Can you disable the floppy drive and controller? There are usually separate options on different screens. -- Adam Vande More From rick-freebsd2009 at kiwi-computer.com Thu Nov 12 21:33:22 2009 From: rick-freebsd2009 at kiwi-computer.com (Rick C. Petty) Date: Thu Nov 12 21:33:30 2009 Subject: SMART In-Reply-To: <20091112174428.GA24213@icarus.home.lan> References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> <20091112174428.GA24213@icarus.home.lan> Message-ID: <20091112213320.GA67218@keira.kiwi-computer.com> On Thu, Nov 12, 2009 at 09:44:28AM -0800, Jeremy Chadwick wrote: > On Thu, Nov 12, 2009 at 01:25:12PM +0100, Ivan Voras wrote: > > Jeremy Chadwick wrote: > > > > >I can teach you how to decode/read SMART statistics correctly. > > > > Actually, it would be good if you taught more than him :) > > > > I've always wondered how important are each of the dozen or so > > statistics and what indicates what... > > I'll work on writing an actual HTML document to put up on my web site > and will respond with the URL once I finish it. Isn't this sufficient? http://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes If not, could you make the changes on wikipedia? This isn't a FreeBSD-specific topic, and the larger community would benefit from such documentation. -- Rick C. Petty From crapsh at Monkeybrains.net Thu Nov 12 21:43:42 2009 From: crapsh at Monkeybrains.net (Rudy) Date: Thu Nov 12 21:43:49 2009 Subject: KVM tips for bsd as guest? Message-ID: <8E227A3A-661E-43F0-BAFC-EEDD01A804E8@Monkeybrains.net> Downloaded iso, but qemu barfs when trying to install --- loads kernel but panics during boot of 7.2 ( and 8.0-rc3) install ISOs. I am trying to set up a bsd guest ... Host OS is debian. Virtualbox installed no problem. I am looking for a general how-to if there is one out there( tried searching didn't find it). Rudy ------ MonkeyBrains.net ------ Rudy 415.425.9825 From marius at nuenneri.ch Thu Nov 12 21:53:05 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Nov 12 21:53:12 2009 Subject: KVM tips for bsd as guest? In-Reply-To: <8E227A3A-661E-43F0-BAFC-EEDD01A804E8@Monkeybrains.net> References: <8E227A3A-661E-43F0-BAFC-EEDD01A804E8@Monkeybrains.net> Message-ID: On Thu, Nov 12, 2009 at 22:42, Rudy wrote: > > Downloaded iso, but qemu barfs when trying to install --- loads kernel but > panics during boot of 7.2 ( and 8.0-rc3) install ISOs. ?I am trying to set > up a bsd guest ... Host OS is debian. > > Virtualbox installed no problem. > > I am looking for a general how-to if there is one out there( tried searching > didn't find it). What about sending the kernel panic message (with backtrace)? From kenyon at kenyonralph.com Thu Nov 12 21:54:52 2009 From: kenyon at kenyonralph.com (Kenyon Ralph) Date: Thu Nov 12 21:54:59 2009 Subject: 8.0-RC3 Available In-Reply-To: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: <20091112215449.GA21631@kenyonralph.com> On 2009-11-12T10:38:37-0500, Ken Smith wrote: > ISO images for all supported architectures are available on the FTP > sites, and a "memory stick" image is available for amd64/i386 > architectures. For amd64/i386 architectures the cdrom and memstick > images include the documentation packages but no other packages. I just did a successful minimal install on a Dell laptop from the amd64 memstick RC3 media. I created the memstick like this on a GNU/Linux machine: dd if=8.0-RC3-amd64-memstick.img of=/dev/sda bs=10240 conv=sync -- Kenyon Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091112/1fb01492/attachment.pgp From zbeeble at gmail.com Thu Nov 12 21:56:54 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Thu Nov 12 21:57:01 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911121355m5f115c93j7d1908336591fe31@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <6201873e0911121327x8b5a16k86c5018582785396@mail.gmail.com> <5f67a8c40911121355m5f115c93j7d1908336591fe31@mail.gmail.com> Message-ID: <5f67a8c40911121356j608b41dct6ad7c1109b5d0438@mail.gmail.com> On Thu, Nov 12, 2009 at 4:27 PM, Adam Vande More wrote: > On Thu, Nov 12, 2009 at 2:46 PM, Zaphod Beeblebrox wrote: > >> fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on >> acpi0 >> fdc0: does not respond >> device_attach: fdc0 attach returned 6 >> >> If I boot the machine without ACPI, it seems to stop at the same place >> (stopping after having checked the ata controller, which checks right >> before >> the floppy) >> >> If I boot the machine verbose, I get no more information --- it stopps at >> the same place. >> > > Can you disable the floppy drive and controller? There are usually > separate options on different screens. > I've now verified that 8.0-RC3 does the same thing, BTW. Anyways... no. There is no floppy option in the BIOS. It's not in any of the sub-menus (which is how Dell's BIOS is organized). I'm also not-so-sure that the floppy is where it's stopping because the non-ACPI boot doesn't mention the floppy at all ... leading me to believe it's whatever is checked "after" the floppy that is at fault... but even the verbose boot doesn't let me know what that might be. From niktychina at gmail.com Thu Nov 12 22:00:16 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Thu Nov 12 22:00:35 2009 Subject: how to mirror cvs or svn with rsync Message-ID: Hi everybody! How do I mirror FreeBSD sources (CVS or SVN) with rsync? This is the first time I have to use rsync, and its man page really makes me confused. I would really appreciate your help. Regards, Nik From Hans.F.Nordhaug at hiMolde.no Thu Nov 12 22:50:21 2009 From: Hans.F.Nordhaug at hiMolde.no (Hans F. Nordhaug) Date: Thu Nov 12 22:50:29 2009 Subject: /bin/sh core dumps on FreeBSD 7.2 In-Reply-To: <20091112115350.GA18542@icarus.home.lan> References: <20091112103308.GA2536@hiMolde.no> <20091112115350.GA18542@icarus.home.lan> Message-ID: <20091112225017.GA13095@hiMolde.no> * Jeremy Chadwick [2009-11-12]: > On Thu, Nov 12, 2009 at 11:33:08AM +0100, Hans F. Nordhaug wrote: > > Suddenly /bin/sh started to crash all the time with core dumps. I'm > > running FreeBSD 7.2-RELEASE-p4 (i386) and I have not updated anything > > lately. The /bin/sh binary seems to be untouched. It might be some > > hardware trouble, but the machine seems to run OK now. (I had to > > replace /bin/sh with a symlink to /rescue/sh.) > > > > I would like to track down the problem, but running sh I only get > > "Segmentation fault: 11 (core dumped)". I would be happy to run > > gdb and give you a backtrace. Any clues? > > > > PS! I tried to run "freebsd-update IDS" to see if any files are > > broken, but it stops at > > Inspecting system... sha256: ///boot/kernel/utopia.ko.symbols: Input/output error > > Hardware problem. Take your pick: bad RAM, bad hard disk, bad > motherboard, bad PSU, bad cabling. > > You can rule out hard disk problems by installing smartmontools from > ports (sysutils/smartmontools). Please provide output from the > following command: > > smartctl -a /dev/{disk} Thx for the infp about smartmontools. The only problem I found was: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 190 Airflow_Temperature_Cel 0x0022 001 001 045 Old_age Always FAILING_NOW 253 Don't know if this is a serious problem. Hans PS! The disk is of type Model Family: Western Digital Caviar Second Generation Serial ATA family Device Model: WDC WD2500JS-55NCB1 From fjwcash at gmail.com Thu Nov 12 22:51:17 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Nov 12 22:51:24 2009 Subject: KVM tips for bsd as guest? In-Reply-To: References: <8E227A3A-661E-43F0-BAFC-EEDD01A804E8@Monkeybrains.net> Message-ID: On Thu, Nov 12, 2009 at 1:53 PM, Marius N?nnerich wrote: > On Thu, Nov 12, 2009 at 22:42, Rudy wrote: >> Downloaded iso, but qemu barfs when trying to install --- loads kernel but >> panics during boot of 7.2 ( and 8.0-rc3) install ISOs. ?I am trying to set >> up a bsd guest ... Host OS is debian. i386 or amd64? What are your KVM settings? Number of CPUs, amount of RAM, type of virtual disk (IDE/SCSI), type of NIC (rtl3189/e1000)? Which CPU is in the host server (AMD/Intel)? And which versions of KVM and Linux kernel are you running? Last time I tested was with KVM-72 on 64-bit Debian using kernel 2.6.26, and installing/running FreeBSD 6.x and 7.x, 32-bit and 64-bit, ran without any issues. Used LVM-backed virtual IDE drives, and e1000 NICs. Granted, we use AMD Opteron CPUs, which seem to have fewer issues with KVM than Intel Xeon CPUs. >> I am looking for a general how-to if there is one out there( tried searching >> didn't find it). There's no real How-To needed. Just configure the VM, and boot. This is the first time I've heard of issues with installing FreeBSD into KVM-managed VMs. -- Freddie Cash fjwcash@gmail.com From royce.williams at gmail.com Thu Nov 12 23:44:08 2009 From: royce.williams at gmail.com (Royce Williams) Date: Thu Nov 12 23:44:15 2009 Subject: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R) In-Reply-To: <20091112204736.GA29095@icarus.home.lan> References: <4AFC63B0.5020707@alaska.net> <20091112204736.GA29095@icarus.home.lan> Message-ID: <9dd082310911121518l24adaa23jdb41ff567374d11c@mail.gmail.com> On Thu, Nov 12, 2009 at 11:47 AM, Jeremy Chadwick wrote: > Please define "low-throughput" and "high-volume" if you could; it might > help folks determine where the threshold is for problems. My definitions are pretty subjective/operational, but for what it's worth: - "low" is interactive SSH, DNS lookups, and pings; - "high" is a single unthrottled rsync session. >> rand# sysctl dev.em >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6 >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 subdevice=0x108c class=0x020000 >> kenv: >> >> rand# kenv | grep smbios | egrep -v 'socket|serial|uuid|tag|0123456789' >> smbios.bios.reldate="03/05/2008" > For what it's worth as a comparison base: > > We use the following Supermicro SuperServers, and can confirm that no > such issues occur for us using RELENG_6 nor RELENG_7 on the following > hardware: [good cross-check list snipped] The problem system is a 5015M-MF. We are running 5015M-MT+ and 5015T-PR on RELENG_6 and 7, both without the symptom. > Relevant server configuration and network setup details: > > - All machines use pf(4). > - All emX devices are configured for autoneg. > - All emX devices use RXCSUM, TXCSUM, and TSO4. > - We do not use polling. > - All machines use both NICs simultaneously at all times. > - All machines connected to an HP ProCurve 2626 switch (100mbit, > ?full-duplex ports, all autoneg). > - We do not use Jumbo frames. > - No add-in cards (PCI, PCI-X, nor PCIe) are used in the systems. > - All of the systems had DCGDIS.EXE run on them; no EEPROM settings > ?were changed, indicating the from-the-Intel-factory MANC register > ?in question was set properly. No firewall is active on the problem system, and none of this back have been DCGDIS-ified, but otherwise, our setup is identical. > I've compared your sysctl dev.em output to that of our 5015M-T+B systems > (which use the PDSMi+, not the PDSMi, but whatever), and ours is 100% > identical. > > All of our 5015M-T+B systems are using BIOS 1.3, and the 5015B-MTB > system is using BIOS 1.30. The repurposed system is at 1.3 (03/05/2008) - flashed prior to install. The production 6.3 systems are using 1.1 (or 1.1A, would have to reboot to check, but the date is 10/27/2005). > If you'd like, I can provide the exact BIOS settings we use on the > machines in question; they do deviate from the factory defaults a slight > bit, but none of the adjustments are "tweaks" for performance or > otherwise (just disabling things which we don't use, etc.). We're running similarly as well. I might be able to retire another system of this batch and install 7.2, but leave the BIOS update off, to see if it makes a difference. Royce From dan at langille.org Fri Nov 13 02:00:04 2009 From: dan at langille.org (Dan Langille) Date: Fri Nov 13 02:00:11 2009 Subject: hald running 100% Message-ID: <4AFCBD9C.1030306@langille.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both my laptop and my desktop: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% hald uptime was about 1:50 at this point. Seems to be relatively common from the posts I've seen. ThinkPad X61s. dmesg output attached. FWIW. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr8vZwACgkQCgsXFM/7nTzTmwCgwSlroEPuQ8cL3U8THAlFVp7v waIAmwRjRzNkjCUffuzhvKwj/wK5i5f6 =yVNP -----END PGP SIGNATURE----- -------------- next part -------------- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-PRERELEASE #2: Thu Nov 12 10:44:46 EST 2009 dan@laptop.example.org:/usr/obj/usr/src/sys/LAPTOP amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (1596.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4024070144 (3837 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 20090521 tbfadt-625 ACPI Warning: Optional field Gpe1Block has zero address or length: 0 102C/0 20090521 tbfadt-655 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xf8000000-0xf80fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf8100000-0xf81fffff at device 2.1 on pci0 em0: port 0x1840-0x185f mem 0xf8200000-0xf821ffff,0xf8225000-0xf8225fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1d:72:86:96:3c uhci0: port 0x1860-0x187f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1880-0x189f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 ehci0: mem 0xf8426c00-0xf8426fff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 hdac0: mem 0xf8220000-0xf8223fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib1: irq 20 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 21 at device 28.1 on pci0 pci3: on pcib2 ath0: mem 0xf7f00000-0xf7f0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: AR5413 mac 10.3 RF5424 phy 6.1 uhci2: port 0x18a0-0x18bf irq 16 at device 29.0 on pci0 uhci2: [ITHREAD] usbus3: on uhci2 uhci3: port 0x18c0-0x18df irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 ehci1: mem 0xf8427000-0xf84273ff irq 19 at device 29.7 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pcib3: at device 30.0 on pci0 pci5: on pcib3 cbb0: mem 0xd7eff000-0xd7efffff irq 16 at device 0.0 on pci5 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] fwohci0: <1394 Open Host Controller Interface> mem 0xd7efe800-0xd7efefff irq 17 at device 0.1 on pci5 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1d:72:ff:86:96:3c:ff fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1570000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1d:72:96:3c:ff fwe0: Ethernet address: 02:1d:72:96:3c:ff fwip0: on firewire0 fwip0: Firewire address: 00:1d:72:ff:86:96:3c:ff @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode pci5: at device 0.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18e0-0x18ef at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x1c30-0x1c37,0x1c24-0x1c27,0x1c28-0x1c2f,0x1c20-0x1c23,0x1c00-0x1c1f mem 0xf8426000-0xf84267ff irq 16 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI v1.10 controller with 3 1.5Gbps ports, PM not supported ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xe0000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master SATA150 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 hdac0: HDA Codec #0: Analog Devices AD1984 hdac0: HDA Codec #1: Conexant (Unknown) GEOM: ad4: partition 2 does not start on a track boundary. GEOM: ad4: partition 2 does not end on a track boundary. GEOM: ad4: partition 1 does not start on a track boundary. GEOM: ad4: partition 1 does not end on a track boundary. pcm0: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! GEOM: ad4s3: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered Root mount waiting for: usbus5 usbus2 uhub2: 4 ports with 4 removable, self powered uhub5: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ad4s3a wlan0: Ethernet address: 00:1f:3a:08:5f:97 From royce.williams at gmail.com Fri Nov 13 02:57:00 2009 From: royce.williams at gmail.com (Royce Williams) Date: Fri Nov 13 02:57:07 2009 Subject: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R) In-Reply-To: <9dd082310911121518l24adaa23jdb41ff567374d11c@mail.gmail.com> References: <4AFC63B0.5020707@alaska.net> <20091112204736.GA29095@icarus.home.lan> <9dd082310911121518l24adaa23jdb41ff567374d11c@mail.gmail.com> Message-ID: <9dd082310911121856te64bc71x5cad46199d38f53e@mail.gmail.com> On Thu, Nov 12, 2009 at 2:18 PM, Royce Williams wrote: > On Thu, Nov 12, 2009 at 11:47 AM, Jeremy Chadwick >> - All machines connected to an HP ProCurve 2626 switch (100mbit, >> ?full-duplex ports, all autoneg). > No firewall is active on the problem system, and none of this back > have been DCGDIS-ified, but otherwise, our setup is identical. Er, s/back/batch/g, and it's not a ProCurve. ;-) But we are also usually full-duplex and autoneg on both sides. Based on new (embarrassing) information, I'll leave it to Jack to decide whether or not he wants to pursue this further. The problem box is sitting in my grotty mini-lab, with a subnet partially serviced by a 10M hub. Guess which Ethernet cable I picked up. Guess what happens when I move the system to a 100M/full connection. As my cow-orker put it, "You and the other four people on Earth using that NIC on 10M hubs" can probably find workarounds. My apologies for the noise, though it's theoretically possible that the root cause might still need addressing. Jack, let me know if you want me to do any testing for you. Or I can always send you my hub. ;-) Royce From amvandemore at gmail.com Fri Nov 13 03:02:03 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Fri Nov 13 03:02:10 2009 Subject: hald running 100% In-Reply-To: <4AFCBD9C.1030306@langille.org> References: <4AFCBD9C.1030306@langille.org> Message-ID: <6201873e0911121902m72d7cefbne11023abb511f693@mail.gmail.com> On Thu, Nov 12, 2009 at 7:59 PM, Dan Langille wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both > my laptop and my desktop: > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% hald > > uptime was about 1:50 at this point. > > Seems to be relatively common from the posts I've seen. > > > ThinkPad X61s. dmesg output attached. FWIW. > > it's not a common issue anymore. What version of hal are you running and did you recompile after the upgrade? -- Adam Vande More From jfvogel at gmail.com Fri Nov 13 04:07:13 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Nov 13 04:07:20 2009 Subject: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R) In-Reply-To: <9dd082310911121856te64bc71x5cad46199d38f53e@mail.gmail.com> References: <4AFC63B0.5020707@alaska.net> <20091112204736.GA29095@icarus.home.lan> <9dd082310911121518l24adaa23jdb41ff567374d11c@mail.gmail.com> <9dd082310911121856te64bc71x5cad46199d38f53e@mail.gmail.com> Message-ID: <2a41acea0911122007r12e4d02ew6e2817f32714d381@mail.gmail.com> LOL, glad the problem has been resolved, and no thanks, I do not need to pursue this any further. I also want to thank Jeremy for his help and data!! Thanks guys and good evening, Jack On Thu, Nov 12, 2009 at 6:56 PM, Royce Williams wrote: > On Thu, Nov 12, 2009 at 2:18 PM, Royce Williams > wrote: > > On Thu, Nov 12, 2009 at 11:47 AM, Jeremy Chadwick > >> - All machines connected to an HP ProCurve 2626 switch (100mbit, > >> full-duplex ports, all autoneg). > > > No firewall is active on the problem system, and none of this back > > have been DCGDIS-ified, but otherwise, our setup is identical. > > Er, s/back/batch/g, and it's not a ProCurve. ;-) But we are also > usually full-duplex and autoneg on both sides. > > Based on new (embarrassing) information, I'll leave it to Jack to > decide whether or not he wants to pursue this further. > > The problem box is sitting in my grotty mini-lab, with a subnet > partially serviced by a 10M hub. Guess which Ethernet cable I picked > up. Guess what happens when I move the system to a 100M/full > connection. > > As my cow-orker put it, "You and the other four people on Earth using > that NIC on 10M hubs" can probably find workarounds. My apologies for > the noise, though it's theoretically possible that the root cause > might still need addressing. > > Jack, let me know if you want me to do any testing for you. Or I can > always send you my hub. ;-) > > Royce > From welcome at linkedin.com Fri Nov 13 04:57:50 2009 From: welcome at linkedin.com (LinkedIn) Date: Fri Nov 13 04:57:57 2009 Subject: Welcome to LinkedIn! Message-ID: <834832830.9110421.1258086584125.JavaMail.app@ech3-cdn12.prod> Thank you for using LinkedIn! You have joined over 50 million professionals using LinkedIn to stay connected and reach new people through trusted referrals. Get Things Done... Better and Faster Use LinkedIn to get whatever job you do today done better -- it's the best way to connect with: * job candidates * industry experts * business partners * hiring managers Search your network now: http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/sea/wel_search_02_A/ Find Contacts The average LinkedIn user knows 15 to 20 people who already have their professional network on LinkedIn. You probably do, too. Find out which of the people you know are already "LinkedIn": http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/fdc/wel_findcts_02_A/ How LinkedIn Works To learn more about LinkedIn, come and take our tour: http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/tou/wel_tour_02_A/ Welcome! - Your LinkedIn Team http://www.linkedin.com/ Your email: freebsd-stable@FreeBSD.ORG Add additional emails: https://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/mep/wel_addemail_02_A/ Edit profile: http://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/mpe/wel_editpro_02_A/ Contact settings: https://www.linkedin.com/e/TGrSvDCw7IOFPvo9di0rrrCxHfruWXUdu2q0FyGg/csp/wel_cntset_02_A/ From quakelee at geekcn.org Fri Nov 13 08:42:56 2009 From: quakelee at geekcn.org (Chao Shin) Date: Fri Nov 13 08:43:04 2009 Subject: 8.0-RC3 Available In-Reply-To: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: Hi All, Is sysinstall can work now? After I set Label in sysinstall it has message come out said "Unable to find device node for /dev/ad4s1b in /dev! The creation of filesystems will be aborted." and installation aborted. I have installed freebsd with sysinstall ten years, that is first time I meet that > > The third and hopefully last of the Release Candidates for the FreeBSD > 8.0 release cycle is now available. Unless something catastrophic comes > up within the next couple of days we will begin the final builds for > 8.0-RELEASE. > > There is one known issue with the igb(4) driver we are still deciding > whether or not to fix as part of 8.0-RELEASE versus doing an Errata > Notice for it some time after the release is out. It has been patched > in head, and the SVN commit for it is r199192. If any of you are able > to give that patch a try on a machine with the igb(4) NIC it would be > appreciated. > > If you notice problems you can report them through the normal Gnats PR > system or on the freebsd-current mailing list. I do cross-post > announcements to freebsd-stable because this particular release is > "about to become a stable branch" but when it comes to watching for > issues related to the release most of the developers pay more attention > to the freebsd-current list. > > ISO images for all supported architectures are available on the FTP > sites, and a "memory stick" image is available for amd64/i386 > architectures. For amd64/i386 architectures the cdrom and memstick > images include the documentation packages but no other packages. The > DVD image includes the packages that will probably be available on the > official release media but is subject to change between now and release. > For sparc64 there is now a livefs cdrom, disc1 includes the > documentation packages, and the DVD image has the set of packages that > currently build for sparc64 (which is a sub-set of the set provided for > amd64/i386). > > If you are using csup/cvsup methods to update an older system the branch > tag to use is RELENG_8_0. > > The freebsd-update(8) utility supports binary upgrades of i386 and amd64 > systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, > 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, > 8.0-RC1 or 8.0-RC2 can upgrade as follows: > # freebsd-update upgrade -r 8.0-RC3 > During this process, FreeBSD Update may ask the user to help by merging > some configuration files or by confirming that the automatically > performed merging was done correctly. Systems running 8.0-BETA3 may > print the warning > > INDEX-OLD.all: Invalid arguments > > when downloading updates; this warning is a harmless bug (fixed in > 8.0-BETA4) and can be safely ignored. > > # freebsd-update install > The system must be rebooted with the newly installed kernel before > continuing. > # shutdown -r now > After rebooting, freebsd-update needs to be run again to install the new > userland components: > > # freebsd-update install > At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or > earlier will be prompted by freebsd-update to rebuild all third-party > applications (e.g., ports installed from the ports tree) due to updates > in system libraries. See: > > http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html > > for mode details. After updating installed third-party applications > (and again, only if freebsd-update printed a message indicating that > this was necessary), run freebsd-update again so that it can delete the > old (no longer used) system libraries: > > # freebsd-update install > Finally, reboot into 8.0-RC3: > # shutdown -r now > > MD5/SHA256 checksums for the image files: > > MD5 (8.0-RC3-amd64-bootonly.iso) = 641881caa82ea85c118bc15fff12fce6 > MD5 (8.0-RC3-amd64-disc1.iso) = 854c273b89792cd0366d5399df1034eb > MD5 (8.0-RC3-amd64-dvd1.iso) = 9bd1bb2507bc2a3037bc321bb2724bd6 > MD5 (8.0-RC3-amd64-livefs.iso) = c5f427c8bf823e10a5348935cec2d7ee > MD5 (8.0-RC3-amd64-memstick.img) = 6af9e213914a58a5779715ae5882bd25 > > MD5 (8.0-RC3-i386-bootonly.iso) = dfaec92ae358ab780d317aa66482ca9e > MD5 (8.0-RC3-i386-disc1.iso) = 460f6cfddaebee6ae59a7d5f73695246 > MD5 (8.0-RC3-i386-dvd1.iso) = 98d3f65f2444a8745f787df5ce9e1f0c > MD5 (8.0-RC3-i386-livefs.iso) = 5184b7f6403d1d24991533bde0e580ff > MD5 (8.0-RC3-i386-memstick.img) = 8774ef1d6bdf541e440f2f8ed22a2493 > > MD5 (8.0-RC3-ia64-bootonly.iso) = fd0af8f34937cf7fc78ea0063252afb7 > MD5 (8.0-RC3-ia64-disc1.iso) = 96313c25e53fc333c258ed675007f3d7 > MD5 (8.0-RC3-ia64-disc2.iso) = 235714607a2805c396ece829839405be > MD5 (8.0-RC3-ia64-disc3.iso) = 53fca9243ccc788190ca58d24f363cbe > MD5 (8.0-RC3-ia64-dvd1.iso) = 4e24736ab50bc2227c72dbeab6869266 > MD5 (8.0-RC3-ia64-livefs.iso) = b6d76cf77ed714631bf714ff78b8e950 > > MD5 (8.0-RC3-pc98-bootonly.iso) = 137d17ec3830b6ae831b6fb48adf86e0 > MD5 (8.0-RC3-pc98-disc1.iso) = 3624b1f7b3a659a7454718e38b9a1ee0 > MD5 (8.0-RC3-pc98-livefs.iso) = 29ed3786b2df1c2e72e45d1187f3e788 > MD5 (8.0-RC3-powerpc-bootonly.iso) = e7d8508639dee4aed5e52a24d6e27b69 > MD5 (8.0-RC3-powerpc-disc1.iso) = 1016ae7753db153b7be0f5d167f595b9 > MD5 (8.0-RC3-powerpc-disc2.iso) = aec2400454631cc2eaecb6f618bfecc8 > MD5 (8.0-RC3-powerpc-disc3.iso) = fe36d621ad4b6347f8ade9800ccfab7b > > MD5 (8.0-RC3-sparc64-bootonly.iso) = c35ddcb4dd050c793d89973eba02df72 > MD5 (8.0-RC3-sparc64-disc1.iso) = 0d3855603ac868609fb882c321555508 > MD5 (8.0-RC3-sparc64-dvd1.iso) = 7a402ec8d17804bd6d16fad0969c9e52 > MD5 (8.0-RC3-sparc64-livefs.iso) = 61c90ecce584c0c91f91e744f40a7d42 > > SHA256 (8.0-RC3-amd64-bootonly.iso) = > fbf7c68cf81c300ec4e944ed6491f65d217168a85c1863c019cb41eec30cae94 > SHA256 (8.0-RC3-amd64-disc1.iso) = > 7e377f38cb6dc0ba1aa1fa13facf7e03f3cefad3d1490de797ed3a91680892e8 > SHA256 (8.0-RC3-amd64-dvd1.iso) = > fa4671d9b9b5b8208579d51cc2f72188a9537984ee28ba851236a52f32022597 > SHA256 (8.0-RC3-amd64-livefs.iso) = > c8c3728583b43e76d5e305b20fed578474adb5b14dbf2537b8ca9156b2d1c4cd > SHA256 (8.0-RC3-amd64-memstick.img) = > b8d90dbfca07160d9818bf6705b5dd99ba25fe1624cdda3f3f4919681d1b1af1 > > SHA256 (8.0-RC3-i386-bootonly.iso) = > f514dbec335fbf72917b25c1e79f6bca4e9dd74e037f75ab30d810e7942ac2fc > SHA256 (8.0-RC3-i386-disc1.iso) = > 6b306af4a74df57d2c155891557878d747bac92a24c2b46947f89e7d9657addc > SHA256 (8.0-RC3-i386-dvd1.iso) = > 21794b11142eeb7eb56c8810b83dcd67230b0d26a0f0e5839866172d977a5626 > SHA256 (8.0-RC3-i386-livefs.iso) = > 3dfd45e0a5550913b29d19d989f19167159d1f926f1667d1622890a5f83be93b > SHA256 (8.0-RC3-i386-memstick.img) = > afc65bf14101ace1f069323678a8070ab84823bf191aeefa8fc9909d38e9306e > > SHA256 (8.0-RC3-ia64-bootonly.iso) = > 1fefdd0b03c943162cbb66d507e11c3a2e541e97a0742471de49f17ae96b953c > SHA256 (8.0-RC3-ia64-disc1.iso) = > 67124c8101dd3fb06dbd3771c3eb18560207b42e46c331cc2ab02ba5284a72b7 > SHA256 (8.0-RC3-ia64-disc2.iso) = > 4eaa1125f98c5ed463f7577b9818dd57dbaee0bad01a1c7543ad4cc89c1770d0 > SHA256 (8.0-RC3-ia64-disc3.iso) = > c178a48004a12d6f178b478da146582742a88a27fcbf380029ae7fb3f6db6472 > SHA256 (8.0-RC3-ia64-dvd1.iso) = > d45a8e6ae622c1985d5b9c346c74f44884f3adba3c02d0b69bb58f19b359fa73 > SHA256 (8.0-RC3-ia64-livefs.iso) = > 9132340e15b75601017b0b57902fa48926e1d1a257f1f5149baa07c15e0dede8 > > SHA256 (8.0-RC3-pc98-bootonly.iso) = > 42beee44af5859861718978a03de04e6a6fd0e63afec66a939830286fb73b22a > SHA256 (8.0-RC3-pc98-disc1.iso) = > 4b00447579349443d80082d1809b0d04688ea317a9bee3f551c13a35c82c549d > SHA256 (8.0-RC3-pc98-livefs.iso) = > 243306c98a9eade16d90994217fd89f0aba51cfd8399b1017754a3415f2e79e8 > > SHA256 (8.0-RC3-powerpc-bootonly.iso) = > 4cfbcac5fc69bb10860ed2c511bcf175be730c2fd11e57ccd2c8c77322ea5172 > SHA256 (8.0-RC3-powerpc-disc1.iso) = > 6d7725d24c01d985590566eb168cde1e6d334a3cdc6bdc7a4508ea54c205c489 > SHA256 (8.0-RC3-powerpc-disc2.iso) = > ecfd22166dd411359d74a61c1724cfa747e4a7e9cb8b47776643795f6388942b > SHA256 (8.0-RC3-powerpc-disc3.iso) = > fc3c0c2823b36cc6530c7afdb73dbfa3cb1bf6a64a59fd4a55307e1e4d1541fe > > SHA256 (8.0-RC3-sparc64-bootonly.iso) = > 44a641e1f3080112d6063f923d1e5d17f9d9eedd1004888aace77e08beca2fdf > SHA256 (8.0-RC3-sparc64-disc1.iso) = > e68eec5765f9313a9cbe4e94915b89d68caa4f4f65884be9e7b1d463862c17e3 > SHA256 (8.0-RC3-sparc64-dvd1.iso) = > e824cc316c520d29673c51e5ccf58aba9a79b17e7b61b67c1d13da7300911f7b > SHA256 (8.0-RC3-sparc64-livefs.iso) = > a4f0f8f02a9b1bad01088f5cb81a9a4d93ef6aad095afdd79cb5525b4a1e53b5 > -- The Power to Serve From quakelee at geekcn.org Fri Nov 13 08:54:27 2009 From: quakelee at geekcn.org (Chao Shin) Date: Fri Nov 13 08:54:34 2009 Subject: 8.0-RC3 Available In-Reply-To: References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: > Hi All, > > Is sysinstall can work now? > After I set Label in sysinstall it has message come out said > "Unable to find device node for /dev/ad4s1b in /dev! > The creation of filesystems will be aborted." > and installation aborted. > > I have installed freebsd with sysinstall ten years, that is first time I > meet that > my box is dell's optiplex 745, I've installed 7.2R on it without any problem before. >> >> The third and hopefully last of the Release Candidates for the FreeBSD >> 8.0 release cycle is now available. Unless something catastrophic comes >> up within the next couple of days we will begin the final builds for >> 8.0-RELEASE. >> >> There is one known issue with the igb(4) driver we are still deciding >> whether or not to fix as part of 8.0-RELEASE versus doing an Errata >> Notice for it some time after the release is out. It has been patched >> in head, and the SVN commit for it is r199192. If any of you are able >> to give that patch a try on a machine with the igb(4) NIC it would be >> appreciated. >> >> If you notice problems you can report them through the normal Gnats PR >> system or on the freebsd-current mailing list. I do cross-post >> announcements to freebsd-stable because this particular release is >> "about to become a stable branch" but when it comes to watching for >> issues related to the release most of the developers pay more attention >> to the freebsd-current list. >> >> ISO images for all supported architectures are available on the FTP >> sites, and a "memory stick" image is available for amd64/i386 >> architectures. For amd64/i386 architectures the cdrom and memstick >> images include the documentation packages but no other packages. The >> DVD image includes the packages that will probably be available on the >> official release media but is subject to change between now and release. >> For sparc64 there is now a livefs cdrom, disc1 includes the >> documentation packages, and the DVD image has the set of packages that >> currently build for sparc64 (which is a sub-set of the set provided for >> amd64/i386). >> >> If you are using csup/cvsup methods to update an older system the branch >> tag to use is RELENG_8_0. >> >> The freebsd-update(8) utility supports binary upgrades of i386 and amd64 >> systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, >> 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, >> 8.0-RC1 or 8.0-RC2 can upgrade as follows: >> # freebsd-update upgrade -r 8.0-RC3 >> During this process, FreeBSD Update may ask the user to help by merging >> some configuration files or by confirming that the automatically >> performed merging was done correctly. Systems running 8.0-BETA3 may >> print the warning >> >> INDEX-OLD.all: Invalid arguments >> >> when downloading updates; this warning is a harmless bug (fixed in >> 8.0-BETA4) and can be safely ignored. >> >> # freebsd-update install >> The system must be rebooted with the newly installed kernel before >> continuing. >> # shutdown -r now >> After rebooting, freebsd-update needs to be run again to install the new >> userland components: >> >> # freebsd-update install >> At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or >> earlier will be prompted by freebsd-update to rebuild all third-party >> applications (e.g., ports installed from the ports tree) due to updates >> in system libraries. See: >> >> http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html >> >> for mode details. After updating installed third-party applications >> (and again, only if freebsd-update printed a message indicating that >> this was necessary), run freebsd-update again so that it can delete the >> old (no longer used) system libraries: >> >> # freebsd-update install >> Finally, reboot into 8.0-RC3: >> # shutdown -r now >> >> MD5/SHA256 checksums for the image files: >> >> MD5 (8.0-RC3-amd64-bootonly.iso) = 641881caa82ea85c118bc15fff12fce6 >> MD5 (8.0-RC3-amd64-disc1.iso) = 854c273b89792cd0366d5399df1034eb >> MD5 (8.0-RC3-amd64-dvd1.iso) = 9bd1bb2507bc2a3037bc321bb2724bd6 >> MD5 (8.0-RC3-amd64-livefs.iso) = c5f427c8bf823e10a5348935cec2d7ee >> MD5 (8.0-RC3-amd64-memstick.img) = 6af9e213914a58a5779715ae5882bd25 >> >> MD5 (8.0-RC3-i386-bootonly.iso) = dfaec92ae358ab780d317aa66482ca9e >> MD5 (8.0-RC3-i386-disc1.iso) = 460f6cfddaebee6ae59a7d5f73695246 >> MD5 (8.0-RC3-i386-dvd1.iso) = 98d3f65f2444a8745f787df5ce9e1f0c >> MD5 (8.0-RC3-i386-livefs.iso) = 5184b7f6403d1d24991533bde0e580ff >> MD5 (8.0-RC3-i386-memstick.img) = 8774ef1d6bdf541e440f2f8ed22a2493 >> >> MD5 (8.0-RC3-ia64-bootonly.iso) = fd0af8f34937cf7fc78ea0063252afb7 >> MD5 (8.0-RC3-ia64-disc1.iso) = 96313c25e53fc333c258ed675007f3d7 >> MD5 (8.0-RC3-ia64-disc2.iso) = 235714607a2805c396ece829839405be >> MD5 (8.0-RC3-ia64-disc3.iso) = 53fca9243ccc788190ca58d24f363cbe >> MD5 (8.0-RC3-ia64-dvd1.iso) = 4e24736ab50bc2227c72dbeab6869266 >> MD5 (8.0-RC3-ia64-livefs.iso) = b6d76cf77ed714631bf714ff78b8e950 >> >> MD5 (8.0-RC3-pc98-bootonly.iso) = 137d17ec3830b6ae831b6fb48adf86e0 >> MD5 (8.0-RC3-pc98-disc1.iso) = 3624b1f7b3a659a7454718e38b9a1ee0 >> MD5 (8.0-RC3-pc98-livefs.iso) = 29ed3786b2df1c2e72e45d1187f3e788 >> MD5 (8.0-RC3-powerpc-bootonly.iso) = e7d8508639dee4aed5e52a24d6e27b69 >> MD5 (8.0-RC3-powerpc-disc1.iso) = 1016ae7753db153b7be0f5d167f595b9 >> MD5 (8.0-RC3-powerpc-disc2.iso) = aec2400454631cc2eaecb6f618bfecc8 >> MD5 (8.0-RC3-powerpc-disc3.iso) = fe36d621ad4b6347f8ade9800ccfab7b >> >> MD5 (8.0-RC3-sparc64-bootonly.iso) = c35ddcb4dd050c793d89973eba02df72 >> MD5 (8.0-RC3-sparc64-disc1.iso) = 0d3855603ac868609fb882c321555508 >> MD5 (8.0-RC3-sparc64-dvd1.iso) = 7a402ec8d17804bd6d16fad0969c9e52 >> MD5 (8.0-RC3-sparc64-livefs.iso) = 61c90ecce584c0c91f91e744f40a7d42 >> >> SHA256 (8.0-RC3-amd64-bootonly.iso) = >> fbf7c68cf81c300ec4e944ed6491f65d217168a85c1863c019cb41eec30cae94 >> SHA256 (8.0-RC3-amd64-disc1.iso) = >> 7e377f38cb6dc0ba1aa1fa13facf7e03f3cefad3d1490de797ed3a91680892e8 >> SHA256 (8.0-RC3-amd64-dvd1.iso) = >> fa4671d9b9b5b8208579d51cc2f72188a9537984ee28ba851236a52f32022597 >> SHA256 (8.0-RC3-amd64-livefs.iso) = >> c8c3728583b43e76d5e305b20fed578474adb5b14dbf2537b8ca9156b2d1c4cd >> SHA256 (8.0-RC3-amd64-memstick.img) = >> b8d90dbfca07160d9818bf6705b5dd99ba25fe1624cdda3f3f4919681d1b1af1 >> >> SHA256 (8.0-RC3-i386-bootonly.iso) = >> f514dbec335fbf72917b25c1e79f6bca4e9dd74e037f75ab30d810e7942ac2fc >> SHA256 (8.0-RC3-i386-disc1.iso) = >> 6b306af4a74df57d2c155891557878d747bac92a24c2b46947f89e7d9657addc >> SHA256 (8.0-RC3-i386-dvd1.iso) = >> 21794b11142eeb7eb56c8810b83dcd67230b0d26a0f0e5839866172d977a5626 >> SHA256 (8.0-RC3-i386-livefs.iso) = >> 3dfd45e0a5550913b29d19d989f19167159d1f926f1667d1622890a5f83be93b >> SHA256 (8.0-RC3-i386-memstick.img) = >> afc65bf14101ace1f069323678a8070ab84823bf191aeefa8fc9909d38e9306e >> >> SHA256 (8.0-RC3-ia64-bootonly.iso) = >> 1fefdd0b03c943162cbb66d507e11c3a2e541e97a0742471de49f17ae96b953c >> SHA256 (8.0-RC3-ia64-disc1.iso) = >> 67124c8101dd3fb06dbd3771c3eb18560207b42e46c331cc2ab02ba5284a72b7 >> SHA256 (8.0-RC3-ia64-disc2.iso) = >> 4eaa1125f98c5ed463f7577b9818dd57dbaee0bad01a1c7543ad4cc89c1770d0 >> SHA256 (8.0-RC3-ia64-disc3.iso) = >> c178a48004a12d6f178b478da146582742a88a27fcbf380029ae7fb3f6db6472 >> SHA256 (8.0-RC3-ia64-dvd1.iso) = >> d45a8e6ae622c1985d5b9c346c74f44884f3adba3c02d0b69bb58f19b359fa73 >> SHA256 (8.0-RC3-ia64-livefs.iso) = >> 9132340e15b75601017b0b57902fa48926e1d1a257f1f5149baa07c15e0dede8 >> >> SHA256 (8.0-RC3-pc98-bootonly.iso) = >> 42beee44af5859861718978a03de04e6a6fd0e63afec66a939830286fb73b22a >> SHA256 (8.0-RC3-pc98-disc1.iso) = >> 4b00447579349443d80082d1809b0d04688ea317a9bee3f551c13a35c82c549d >> SHA256 (8.0-RC3-pc98-livefs.iso) = >> 243306c98a9eade16d90994217fd89f0aba51cfd8399b1017754a3415f2e79e8 >> >> SHA256 (8.0-RC3-powerpc-bootonly.iso) = >> 4cfbcac5fc69bb10860ed2c511bcf175be730c2fd11e57ccd2c8c77322ea5172 >> SHA256 (8.0-RC3-powerpc-disc1.iso) = >> 6d7725d24c01d985590566eb168cde1e6d334a3cdc6bdc7a4508ea54c205c489 >> SHA256 (8.0-RC3-powerpc-disc2.iso) = >> ecfd22166dd411359d74a61c1724cfa747e4a7e9cb8b47776643795f6388942b >> SHA256 (8.0-RC3-powerpc-disc3.iso) = >> fc3c0c2823b36cc6530c7afdb73dbfa3cb1bf6a64a59fd4a55307e1e4d1541fe >> >> SHA256 (8.0-RC3-sparc64-bootonly.iso) = >> 44a641e1f3080112d6063f923d1e5d17f9d9eedd1004888aace77e08beca2fdf >> SHA256 (8.0-RC3-sparc64-disc1.iso) = >> e68eec5765f9313a9cbe4e94915b89d68caa4f4f65884be9e7b1d463862c17e3 >> SHA256 (8.0-RC3-sparc64-dvd1.iso) = >> e824cc316c520d29673c51e5ccf58aba9a79b17e7b61b67c1d13da7300911f7b >> SHA256 (8.0-RC3-sparc64-livefs.iso) = >> a4f0f8f02a9b1bad01088f5cb81a9a4d93ef6aad095afdd79cb5525b4a1e53b5 >> > > -- The Power to Serve From quakelee at geekcn.org Fri Nov 13 09:26:14 2009 From: quakelee at geekcn.org (Chao Shin) Date: Fri Nov 13 09:26:26 2009 Subject: 8.0-RC3 Available In-Reply-To: References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: ? Fri, 13 Nov 2009 16:42:44 +0800?Chao Shin ??: > Hi All, > > Is sysinstall can work now? > After I set Label in sysinstall it has message come out said > "Unable to find device node for /dev/ad4s1b in /dev! > The creation of filesystems will be aborted." > and installation aborted. > > I have installed freebsd with sysinstall ten years, that is first time I > meet that > I found the reason of that. I've fdisk that disk with dd mode before, the sysinstall can't overwrite the partition record, so can't label on it. If I want to install 8.0-rc3 on that disk, I have to erase the partition record with "dd if=/dev/zero of=/dev/ad4 bs=1M count=1" before installation. -- The Power to Serve From freebsd at jdc.parodius.com Fri Nov 13 09:54:23 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Fri Nov 13 09:54:31 2009 Subject: 8.0-RC3 Available In-Reply-To: References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: <20091113095421.GA46162@icarus.home.lan> On Fri, Nov 13, 2009 at 05:25:54PM +0800, Chao Shin wrote: > ??? Fri, 13 Nov 2009 16:42:44 +0800???Chao Shin ??????: > > >Hi All, > > > >Is sysinstall can work now? > >After I set Label in sysinstall it has message come out said > >"Unable to find device node for /dev/ad4s1b in /dev! > >The creation of filesystems will be aborted." > >and installation aborted. > > > >I have installed freebsd with sysinstall ten years, that is first time I > >meet that > > > > I found the reason of that. I've fdisk that disk with dd mode before, the > sysinstall can't overwrite the partition record, so can't label on it. > If I want to install 8.0-rc3 on that disk, I have to erase the partition > record with "dd if=/dev/zero of=/dev/ad4 bs=1M count=1" before > installation. I've covered this (indirectly) on my blog, documenting that 8.0-RC1's sysinstall "was not doing the right thing" with regards to setting up disks to be fully compatible with the new GEOM improvements. The result was a disk that would work, but GEOM would complain about the disk label not matching geometry. http://koitsu.wordpress.com/2009/10/12/testing-out-freebsd-8-0-rc1/ 8.0-RC2 addressed this by fixing sysinstall to do the Right Thing for new installs. Existing installs, however, will be susceptible to the problem. Note the difference in the disk label between an 8.0-RC1 and 8.0-RC2 system here: http://koitsu.wordpress.com/2009/11/02/testing-out-freebsd-8-0-rc2/ Finally, I'll note that your dd command is horribly excessive. All you need to do is nuke the MBR + PBR and you're good to go. The following should be sufficient: dd if=/dev/zero of=/dev/adX count=5 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From wout at delta-design.be Fri Nov 13 10:01:49 2009 From: wout at delta-design.be (Wout =?ISO-8859-1?Q?Decr=E9?=) Date: Fri Nov 13 10:02:01 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: References: Message-ID: <1258104311.2362.1.camel@wout-thinkpad> Hello Maybe the following article will get you started: http://www.freebsd.org/doc/en/articles/hubs/ Kind regards Wout On Fri, 2009-11-13 at 00:39 +0300, Nikolay Tychina wrote: > Hi everybody! > > How do I mirror FreeBSD sources (CVS or SVN) with rsync? > This is the first time I have to use rsync, and its man page really makes me > confused. > I would really appreciate your help. > > Regards, > > Nik > _______________________________________________ > freebsd-www@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-www > To unsubscribe, send any mail to "freebsd-www-unsubscribe@freebsd.org" > From dan at langille.org Fri Nov 13 11:08:07 2009 From: dan at langille.org (Dan Langille) Date: Fri Nov 13 11:08:15 2009 Subject: hald running 100% In-Reply-To: <6201873e0911121902m72d7cefbne11023abb511f693@mail.gmail.com> References: <4AFCBD9C.1030306@langille.org> <6201873e0911121902m72d7cefbne11023abb511f693@mail.gmail.com> Message-ID: <4AFD3E14.6040403@langille.org> Adam Vande More wrote: > On Thu, Nov 12, 2009 at 7:59 PM, Dan Langille > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both > my laptop and my desktop: > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% hald > > uptime was about 1:50 at this point. > > Seems to be relatively common from the posts I've seen. > > > ThinkPad X61s. dmesg output attached. FWIW. > > > it's not a common issue anymore. What version of hal are you running > and did you recompile after the upgrade? I don't know the version (laptop is not available just now) but I will recompile. That's the next task. Thanks. From rwatson at FreeBSD.org Fri Nov 13 12:23:49 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Nov 13 12:23:56 2009 Subject: [libdispatch-dev] FreeBSD 8-STABLE now supports GCD, libdispatch port updated (fwd) Message-ID: FYI to FreeBSD 8-STABLE followers who may be interested in using Apple's GCD technology on FreeBSD. GCD, for those who may have missed it, is a concurrent programming framework introdued in Mac OS X Snow Leopard, now also supported on FreeBSD. There are a number of useful links on the wiki page, but this provides the best high-level introduction: http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf My announcement text (and wiki link) below. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Fri, 13 Nov 2009 12:21:40 +0000 (GMT) From: Robert Watson To: libdispatch-dev@lists.macosforge.org Subject: [libdispatch-dev] FreeBSD 8-STABLE now supports GCD, libdispatch port updated Dear all: Just an FYI that all the parts are now in place to use GCD (libdispatch) on FreeBSD 8-STABLE. You will need the following: - FreeBSD 8-STABLE snapshot from at least 2009-11-01 (r198732) - FreeBSD libdispatch port from at least 2009-11-11 Do the upgrade to the 8-STABLE snapshot first so that the port can find the required kernel features. As a reminder, you can find FreeBSD/GCD port status, quick start guide, and general information here: http://wiki.freebsd.org/GCD I have updated it to reflect 8.x support. Thanks are due to Stacey Son and Stanislav Sedov for their work to make this happen! Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev From richardtector at thekeelecentre.com Fri Nov 13 14:30:22 2009 From: richardtector at thekeelecentre.com (Richard Tector) Date: Fri Nov 13 14:30:29 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> Message-ID: <4AFD6D69.7090109@thekeelecentre.com> Zaphod Beeblebrox wrote: > I have a dell 1950 here on the floor. Since "1950" seems to refer to a lot > of things with a lot of configurations, I'm going to attempt to narrow that > down a bit. > > It's got 2x 2.33Ghz dual core pentiums (stepping 06-0F-6 according to the > bios) in it and it has an SAS RAID card that FreeBSD recognises. I've > upgraded the BIOS to 2.6.1. It has two SAS 70G drives in a RAID 1 > configuration and it has a DVD (although it will only boot from CDs). > > If it helps, it's between 2 and 3 years old, I think. > > If I allow the machine to boot normally, it stopps after checking the floppy > (there is no floppy) with the following message: > > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > > If I boot the machine without ACPI, it seems to stop at the same place > (stopping after having checked the ata controller, which checks right before > the floppy) > > If I boot the machine verbose, I get no more information --- it stopps at > the same place. > > I have tried this (so far) with 7.2-R and 7.1-R. Both do the same thing. > Can you try with 7.0 (should be available on ftp-archive)? I have a 1950 from Sept '07 that's now running 7.2-STABLE i386 with the fd devices removed. It started out as 7.0-RELEASE, so maybe its a problem introduced since then? Also, you didn't mention if you were running i386 or amd64. Richard From maurovale at gmail.com Fri Nov 13 15:40:34 2009 From: maurovale at gmail.com (M. Vale) Date: Fri Nov 13 15:40:42 2009 Subject: Fwd: hald running 100% In-Reply-To: <85d001330911130707m329d7752w136b6cc43f559e3c@mail.gmail.com> References: <4AFCBD9C.1030306@langille.org> <6201873e0911121902m72d7cefbne11023abb511f693@mail.gmail.com> <4AFD3E14.6040403@langille.org> <85d001330911130707m329d7752w136b6cc43f559e3c@mail.gmail.com> Message-ID: <85d001330911130708p14a43d14j865c6f3c96a0ab4f@mail.gmail.com> ---------- Forwarded message ---------- From: M. Vale Date: 2009/11/13 Subject: Re: hald running 100% To: Dan Langille 2009/11/13 Dan Langille Adam Vande More wrote: > >> On Thu, Nov 12, 2009 at 7:59 PM, Dan Langille > dan@langille.org>> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on >> both >> my laptop and my desktop: >> >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% hald >> >> uptime was about 1:50 at this point. >> >> Seems to be relatively common from the posts I've seen. >> >> >> ThinkPad X61s. dmesg output attached. FWIW. >> >> >> it's not a common issue anymore. What version of hal are you running and >> did you recompile after the upgrade? >> > > I don't know the version (laptop is not available just now) but I will > recompile. That's the next task. Thanks. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Hi Dan, I've found the problem. The problem is that FreeBSD 7.x installs libusb but in 8.0 libusb is already in the kernel and hald behaves badly don't know why. But i've removed the port libusb from my system, recompiled hald and now everything works ok :) Best Regards Mauro V. Edit: Ups forgot to add cc to FreeBSD Stable From traveling08 at cox.net Fri Nov 13 21:17:12 2009 From: traveling08 at cox.net (Robert) Date: Fri Nov 13 21:17:19 2009 Subject: Ext firewire drive not mounted after update Message-ID: <20091113130147.744521d7@asus64> Greetings I just now finished an upgrade to 8.0 Prerelease vie csup, buildworld, make kernel (generic), reboot, mergemaster -p, installworld, mergemaster -Ui, reboot again. [robert@asus64] ~> uname -a FreeBSD asus64.shasta204.local 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #7: Fri Nov 13 12:01:35 PST 2009 root@asus64.shasta204.local:/usr/obj/usr/src/sys/GENERIC amd64 I have a WD external 500G mybook connected via firewire. It has worked fine since 6.something through 7.x and all of the betas and rc's up to this point. I use the drive for backups of all the computers on my network. Booting into multi-user will fail because the drive is not found. I had to comment it out of fstab in order to boot multi-user. If I unplug the firewire cable I get this message on the console: Nov 13 12:42:15 asus64 kernel: fwohci0: fwohci_intr_core: BUS reset Nov 13 12:42:15 asus64 kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=2, CYCLEMASTER mode Nov 13 12:42:15 asus64 kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Nov 13 12:42:15 asus64 kernel: firewire0: bus manager 0 Nov 13 12:42:16 asus64 kernel: firewire0: fw_attach_dev:Removing missing device ID:0090a991e0013e57 Plugging the cable back in gives this: Nov 13 12:42:21 asus64 kernel: fwohci0: fwohci_intr_core: BUS reset Nov 13 12:42:21 asus64 kernel: fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=3, CYCLEMASTER mode Nov 13 12:42:21 asus64 kernel: firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) Nov 13 12:42:21 asus64 kernel: firewire0: bus manager 1 Nov 13 12:42:21 asus64 kernel: firewire0: New S800 device ID:0090a991e0013e57 No device is created in /dev/da* I did not see anything in /usr/src/UPDATING and I do not recall anything like this in the mail lists (currect or stable). Did I miss something or is this a regression? /var/run/dmesg.boot and pciconf -lv attached. I can provide anything else needed. TIA Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.boot Type: application/octet-stream Size: 10052 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091113/fe4344a2/dmesg.obj -------------- next part -------------- none0@pci0:0:0:0: class=0x050000 card=0x81bf1043 chip=0x02f110de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none1@pci0:0:0:1: class=0x050000 card=0x81bf1043 chip=0x02fa10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 0' class = memory subclass = RAM none2@pci0:0:0:2: class=0x050000 card=0x81bf1043 chip=0x02fe10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 1' class = memory subclass = RAM none3@pci0:0:0:3: class=0x050000 card=0x81bf1043 chip=0x02f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 5' class = memory subclass = RAM none4@pci0:0:0:4: class=0x050000 card=0x81bf1043 chip=0x02f910de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 4' class = memory subclass = RAM none5@pci0:0:0:5: class=0x050000 card=0x81bf1043 chip=0x02ff10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none6@pci0:0:0:6: class=0x050000 card=0x81bf1043 chip=0x027f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 3' class = memory subclass = RAM none7@pci0:0:0:7: class=0x050000 card=0x81bf1043 chip=0x027e10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 2' class = memory subclass = RAM pcib1@pci0:0:2:0: class=0x060400 card=0x000010de chip=0x02fc10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:0:3:0: class=0x060400 card=0x000010de chip=0x02fd10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI pcib3@pci0:0:4:0: class=0x060400 card=0x000010de chip=0x02fb10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI vgapci0@pci0:0:5:0: class=0x030000 card=0x81bf1043 chip=0x024210de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVIDIA GeForce 6100 (unknown)' class = display subclass = VGA none8@pci0:0:9:0: class=0x050000 card=0x81c01043 chip=0x027010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Host Bridge' class = memory subclass = RAM isab0@pci0:0:10:0: class=0x060100 card=0x81c01043 chip=0x026110de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 LPC Bridge' class = bridge subclass = PCI-ISA nfsmb0@pci0:0:10:1: class=0x0c0500 card=0x81c01043 chip=0x026410de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVIDIA nForce PCI System Management (NVIDIA SMB Bus Controller)' class = serial bus subclass = SMBus ohci0@pci0:0:11:0: class=0x0c0310 card=0x81c01043 chip=0x026d10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB ehci0@pci0:0:11:1: class=0x0c0320 card=0x81c01043 chip=0x026e10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB atapci0@pci0:0:13:0: class=0x01018a card=0x81c01043 chip=0x026510de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Parallel ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:14:0: class=0x010185 card=0x81c01043 chip=0x026610de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVIDIA nForce 430/410 Serial ATA Controller (MCP51S)' class = mass storage subclass = ATA pcib4@pci0:0:16:0: class=0x060401 card=0x00000000 chip=0x026f10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'MCP51 PCI Bridge' class = bridge subclass = PCI-PCI hdac0@pci0:0:16:1: class=0x040300 card=0xcb8410de chip=0x026c10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 High Definition Audio' class = multimedia subclass = HDA nfe0@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Ethernet Controller (2A34103C)' class = bridge hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' class = bridge subclass = HOST-PCI fwohci0@pci0:4:8:0: class=0x0c0010 card=0x30441106 chip=0x30441106 rev=0x46 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller' class = serial bus subclass = FireWire From traveling08 at cox.net Fri Nov 13 22:50:21 2009 From: traveling08 at cox.net (Robert) Date: Fri Nov 13 22:50:28 2009 Subject: (MORE INFO) Ext firewire drive not mounted after update In-Reply-To: <20091113130147.744521d7@asus64> References: <20091113130147.744521d7@asus64> Message-ID: <20091113145015.647955b9@asus64> On Fri, 13 Nov 2009 13:01:47 -0800 Robert wrote: In the time honored FreeBSD tradition, I am replying to my own email. I booted with a 8.0RC2 livefs CD and the external disk shows up as /dev/da0, /das1, /das1d. I then connected the external drive via USB and rebooted to the 8.0 Prerelease system. The drive shows up and is able to mount. It appears that some thing is amiss with the latest version. I will download the latest livefs iso and see if that works. Robert > Greetings > > I just now finished an upgrade to 8.0 Prerelease vie csup, buildworld, > make kernel (generic), reboot, mergemaster -p, installworld, > mergemaster -Ui, reboot again. > > [robert@asus64] ~> uname -a > FreeBSD asus64.shasta204.local 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE > #7: Fri Nov 13 12:01:35 PST 2009 > root@asus64.shasta204.local:/usr/obj/usr/src/sys/GENERIC amd64 > > I have a WD external 500G mybook connected via firewire. It has worked > fine since 6.something through 7.x and all of the betas and rc's up to > this point. > > I use the drive for backups of all the computers on my network. > Booting into multi-user will fail because the drive is not found. I > had to comment it out of fstab in order to boot multi-user. > > If I unplug the firewire cable I get this message on the console: > > Nov 13 12:42:15 asus64 kernel: fwohci0: fwohci_intr_core: BUS reset > Nov 13 12:42:15 asus64 kernel: fwohci0: fwohci_intr_core: > node_id=0x00000000, SelfID Count=2, CYCLEMASTER mode Nov 13 12:42:15 > asus64 kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) > Nov 13 12:42:15 asus64 kernel: firewire0: bus manager 0 Nov 13 > 12:42:16 asus64 kernel: firewire0: fw_attach_dev:Removing missing > device ID:0090a991e0013e57 > > Plugging the cable back in gives this: > > Nov 13 12:42:21 asus64 kernel: fwohci0: fwohci_intr_core: BUS reset > Nov 13 12:42:21 asus64 kernel: fwohci0: fwohci_intr_core: > node_id=0x00000001, SelfID Count=3, CYCLEMASTER mode Nov 13 12:42:21 > asus64 kernel: firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) > Nov 13 12:42:21 asus64 kernel: firewire0: bus manager 1 Nov 13 > 12:42:21 asus64 kernel: firewire0: New S800 device ID:0090a991e0013e57 > > No device is created in /dev/da* > > I did not see anything in /usr/src/UPDATING and I do not recall > anything like this in the mail lists (currect or stable). > > Did I miss something or is this a regression? /var/run/dmesg.boot and > pciconf -lv attached. I can provide anything else needed. > > TIA > > Robert From dnelson at allantgroup.com Fri Nov 13 23:15:44 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Fri Nov 13 23:15:51 2009 Subject: (MORE INFO) Ext firewire drive not mounted after update In-Reply-To: <20091113145015.647955b9@asus64> References: <20091113130147.744521d7@asus64> <20091113145015.647955b9@asus64> Message-ID: <20091113231539.GN89052@dan.emsphone.com> In the last episode (Nov 13), Robert said: > On Fri, 13 Nov 2009 13:01:47 -0800 > Robert wrote: > > In the time honored FreeBSD tradition, I am replying to my own email. > > I booted with a 8.0RC2 livefs CD and the external disk shows up as > /dev/da0, /das1, /das1d. I then connected the external drive via USB and > rebooted to the 8.0 Prerelease system. The drive shows up and is able to > mount. > > It appears that some thing is amiss with the latest version. I will > download the latest livefs iso and see if that works. I think I remember seing a posting within the last few days saying that the "sbp" device wan't going to be compiled into the 8.0-release kernel due to it causing hangs on boot. If you run "kldload sbp" as root after the system has booted you should see your disk devices appear. I can't find the list post mentioning it, but here's the svn commit log: ------------------------------------------------------------------------ r199112 | kensmith | 2009-11-09 15:39:42 -0600 (Mon, 09 Nov 2009) | 11 lines Changed paths: M /stable/8/sys/amd64/conf/GENERIC M /stable/8/sys/i386/conf/GENERIC M /stable/8/sys/ia64/conf/GENERIC M /stable/8/sys/powerpc/conf/GENERIC M /stable/8/sys/sparc64/conf/GENERIC Comment out the sbp(4) entry for GENERIC config files that contain it. There are known issues with this driver that are beyond what can be fixed for 8.0-RELEASE and the bugs can cause boot failure on some systems. It's not clear if it impacts all systems and there is interest in getting the problem fixed so for now just comment it out instead of remove it. Commit straight to stable/8, this is an 8.0-RELEASE issue. Head was left alone so work on it can continue there. Reviewed by: Primary misc. architecture maintainers (marcel, marius) -- Dan Nelson dnelson@allantgroup.com From dougb at FreeBSD.org Fri Nov 13 23:50:01 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Nov 13 23:50:08 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: References: Message-ID: <4AFDF0AF.1090201@FreeBSD.org> First off, please don't cross post. If you are not sure where to direct a question, the freebsd-questions@freebsd.org list should be your first step. Nikolay Tychina wrote: > Hi everybody! > > How do I mirror FreeBSD sources (CVS or SVN) with rsync? > This is the first time I have to use rsync, and its man page really makes me > confused. > I would really appreciate your help. It would be easier to answer your question if you were more clear about what your goal is. What is it that you are trying to accomplish? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From traveling08 at cox.net Sat Nov 14 00:12:26 2009 From: traveling08 at cox.net (Robert) Date: Sat Nov 14 00:12:34 2009 Subject: (MORE INFO) Ext firewire drive not mounted after update In-Reply-To: <20091113231539.GN89052@dan.emsphone.com> References: <20091113130147.744521d7@asus64> <20091113145015.647955b9@asus64> <20091113231539.GN89052@dan.emsphone.com> Message-ID: <20091113161220.18454229@hp> On Fri, 13 Nov 2009 17:15:39 -0600 Dan Nelson wrote: > In the last episode (Nov 13), Robert said: > > On Fri, 13 Nov 2009 13:01:47 -0800 > > Robert wrote: > > > > > > It appears that some thing is amiss with the latest version. I will > > download the latest livefs iso and see if that works. > > I think I remember seing a posting within the last few days saying > that the "sbp" device wan't going to be compiled into the 8.0-release > kernel due to it causing hangs on boot. If you run "kldload sbp" as > root after the system has booted you should see your disk devices > appear. > > I can't find the list post mentioning it, but here's the svn commit > log: Dan Thanks for responding. I checked and the "sbp" device is in fact commented out. I do remember a thread a month or two back about some folkes having trouble with firewire drives. I never experiem=nced any trouble on of that trouble on this system. I can continue to operate my drive on USB but I may need firewire in the near future. I have a friend who is a photographer and I archive her photos for her. She sends me an external drive or two and I burn her projects onto DVD. I am not sure if her drives have an USB connector. I guess I will cross that bridge when I come to it. Thanks again for the prompt response. If anyone needs me to test possible fixes for this, I am willing and available. Cheap too :-) Robert From zbeeble at gmail.com Sat Nov 14 01:57:57 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Sat Nov 14 01:58:04 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <4AFD6D69.7090109@thekeelecentre.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> Message-ID: <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> On Fri, Nov 13, 2009 at 9:30 AM, Richard Tector < richardtector@thekeelecentre.com> wrote: > > Can you try with 7.0 (should be available on ftp-archive)? > I can confirm that 7.0 exhibits the same behaviour (and is incidentally very chatty about probing the raid controller) > I have a 1950 from Sept '07 that's now running 7.2-STABLE i386 with the fd > devices removed. It started out as 7.0-RELEASE, so maybe its a problem > introduced since then? > > Also, you didn't mention if you were running i386 or amd64. This 1950 may predate that a bit, but I'm not sure how to nail it down exactly, other than by it's hardware components. Anyways, 7.0 does the same thing --- still wedged. From freebsd at jdc.parodius.com Sat Nov 14 02:44:40 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Sat Nov 14 02:44:47 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> Message-ID: <20091114024438.GA93630@icarus.home.lan> On Fri, Nov 13, 2009 at 08:57:56PM -0500, Zaphod Beeblebrox wrote: > On Fri, Nov 13, 2009 at 9:30 AM, Richard Tector < > richardtector@thekeelecentre.com> wrote: > > > Can you try with 7.0 (should be available on ftp-archive)? > > I can confirm that 7.0 exhibits the same behaviour (and is incidentally very > chatty about probing the raid controller) > > > > I have a 1950 from Sept '07 that's now running 7.2-STABLE i386 with the fd > > devices removed. It started out as 7.0-RELEASE, so maybe its a problem > > introduced since then? > > > > Also, you didn't mention if you were running i386 or amd64. > > This 1950 may predate that a bit, but I'm not sure how to nail it down > exactly, other than by it's hardware components. Anyways, 7.0 does the same > thing --- still wedged. I haven't seen anyone recommend this as a test method yet -- disabling fdc prior to the kernel booting via the loader prompt: - Press 6 at the menu, - At the loader prompt, type: set hint.fdc.0.disabled="1" boot -v (or without -v; your choice) You shouldn't need to set hint.fd.0.disabled="1", since fd0 would normally bind to fdc0; disable the latter and you disable the lesser. The intention here is to rule out the device attachment failures from fdc as the source of the deadlock. For sake of comparison, on our systems (non-Dell), this is what we see during fdc/fd probe and shortly after: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 cpu0: on acpi0 I'd have recommended disabling ACPI but you tried it already with the same results. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ivoras at freebsd.org Sat Nov 14 11:37:06 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 14 11:37:13 2009 Subject: Curiously unable to access network - bce, 7.2-RELEASE on a HP blade server Message-ID: The symptoms are: * The device (bce0, bce1) comes up, is visible in ifconfig, can be configured, is UP and RUNNING, everything looks fine * Apparently, it simply doesn't work - no ping responses, TCP, nothing * But tcpdump shows that the NIC apparently does receive multicast router announcements, and some broadcast ARP traffic; only unicast seems to be affected. * Running "netstat 1" shows that apparently there are some packets received - once a second or so, and the "err" counters are 0. * Digging further, the dev.bce.0.stat_IfinFramesL2FilterDiscards contains an increasing number, currently arround 57000 and the dev.bce.0.stat_IfHCInBadOctets also contains an increasing number, currently around 450,000, while ...InOctets is around 30,000 and ...OutBadOctets is 0. From the sysctls it looks like maybe it's discarding valid input packets. I've tried disabling rxcsum, txcsum and TSO without effect. I cannot upgrade or install 8.0 because newusb has some problems with the hardware. Any ideas? From ivoras at freebsd.org Sat Nov 14 12:14:17 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 14 12:14:23 2009 Subject: Curiously unable to access network - bce, 7.2-RELEASE on a HP blade server In-Reply-To: References: Message-ID: I forgot to attach hardware details: bce0: HP NC373i Multifunction Gigabit Server Adapter (B2) ASIC 0x57081021 Rev B2 B/C 0x04040105 Flags 2.5G Additional data point: I cannot reconfigure the card to 100 Mbit operation (currently in 1000baseSX autoselect, full-duplex). Ivan Voras wrote: > The symptoms are: > > * The device (bce0, bce1) comes up, is visible in ifconfig, can be > configured, is UP and RUNNING, everything looks fine > * Apparently, it simply doesn't work - no ping responses, TCP, nothing > * But tcpdump shows that the NIC apparently does receive multicast > router announcements, and some broadcast ARP traffic; only unicast seems > to be affected. > * Running "netstat 1" shows that apparently there are some packets > received - once a second or so, and the "err" counters are 0. > * Digging further, the dev.bce.0.stat_IfinFramesL2FilterDiscards > contains an increasing number, currently arround 57000 and the > dev.bce.0.stat_IfHCInBadOctets also contains an increasing number, > currently around 450,000, while ...InOctets is around 30,000 and > ...OutBadOctets is 0. > > From the sysctls it looks like maybe it's discarding valid input > packets. I've tried disabling rxcsum, txcsum and TSO without effect. > > I cannot upgrade or install 8.0 because newusb has some problems with > the hardware. > > Any ideas? > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From niktychina at gmail.com Sat Nov 14 13:07:05 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Sat Nov 14 13:07:13 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: <4AFDF0AF.1090201@FreeBSD.org> References: <4AFDF0AF.1090201@FreeBSD.org> Message-ID: I need a mirror of FreeBSD sources. But the only one tool I can use for mirroring is rsync. So, now I understand, that even if I get all sourrces from ftp://ftp.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/ I won't be able to check them out without a pain. cheers, Nik It would be easier to answer your question if you were more clear > about what your goal is. What is it that you are trying to accomplish? > > > Doug > > -- > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > From dougb at FreeBSD.org Sat Nov 14 18:30:05 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Nov 14 18:30:12 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: References: <4AFDF0AF.1090201@FreeBSD.org> Message-ID: <4AFEF726.2010200@FreeBSD.org> Nikolay Tychina wrote: > I need a mirror of FreeBSD sources. Nope, not what I asked. :) The question is, what problem are you trying to solve by having a mirror of FreeBSD sources? When we know the answer to that, then we can advise you better. -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From niktychina at gmail.com Sat Nov 14 18:38:13 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Sat Nov 14 18:38:21 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: <4AFEF726.2010200@FreeBSD.org> References: <4AFDF0AF.1090201@FreeBSD.org> <4AFEF726.2010200@FreeBSD.org> Message-ID: Having a mirror accessible from our network for free would help users to get sources for free. Incoming traffic from Internet costs money, that's problem. 2009/11/14 Doug Barton > Nikolay Tychina wrote: > > I need a mirror of FreeBSD sources. > > Nope, not what I asked. :) The question is, what problem are you > trying to solve by having a mirror of FreeBSD sources? When we know > the answer to that, then we can advise you better. > > -- > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > From cpghost at cordula.ws Sat Nov 14 20:16:49 2009 From: cpghost at cordula.ws (cpghost) Date: Sat Nov 14 20:16:56 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: References: <4AFDF0AF.1090201@FreeBSD.org> <4AFEF726.2010200@FreeBSD.org> Message-ID: <20091114201645.GA56393@epia-2.farid-hajji.net> On Sat, Nov 14, 2009 at 09:38:11PM +0300, Nikolay Tychina wrote: > Having a mirror accessible from our network for free would help users to get > sources for free. > Incoming traffic from Internet costs money, that's problem. So you need to mirror /usr/src, and not the whole repository with all its history, right? What I do here is to csup /usr/src on one reference machine every now and then, and then distribute that directory with rsync to all other 500+ machines inside. Actually, I do a little bit more: I compile the sources on the reference machine, and rsync /usr/obj to the other machines too, saving some 500+ buildworlds as well. I could nfs mount /usr/src and /usr/obj from the reference server to the internal machines, but I have enough diskspace there, and rsync is good enough for us. You could also explore a similar mechanism w.r.t. /usr/ports, /usr/local, /var/db/ports, /var/db/pkg etc..., if you want to save external bandwidth downloading ports and distfiles, or CPU cycles compiling all this on your internal machines. But this requires slightly more care, though it works quite well too. -cpghost. -- Cordula's Web. http://www.cordula.ws/ From dan at langille.org Sat Nov 14 20:21:36 2009 From: dan at langille.org (Dan Langille) Date: Sat Nov 14 20:21:44 2009 Subject: hald running 100% In-Reply-To: <4AFD3E14.6040403@langille.org> References: <4AFCBD9C.1030306@langille.org> <6201873e0911121902m72d7cefbne11023abb511f693@mail.gmail.com> <4AFD3E14.6040403@langille.org> Message-ID: <4AFF1151.5040809@langille.org> Dan Langille wrote: > Adam Vande More wrote: >> On Thu, Nov 12, 2009 at 7:59 PM, Dan Langille > > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% >> on both >> my laptop and my desktop: >> >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 1500 haldaemon 1 118 0 22944K 4904K CPU1 1 107:44 100.00% >> hald >> >> uptime was about 1:50 at this point. >> >> Seems to be relatively common from the posts I've seen. >> >> >> ThinkPad X61s. dmesg output attached. FWIW. >> >> >> it's not a common issue anymore. What version of hal are you running >> and did you recompile after the upgrade? > > I don't know the version (laptop is not available just now) but I will > recompile. That's the next task. Thanks. I deleted the libusb library, then recompiled everything that depended upon it. It's running fine now. Thank you. FYI: I've also recompiled all other packages. From niktychina at gmail.com Sat Nov 14 20:39:06 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Sat Nov 14 20:39:12 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: <20091114201645.GA56393@epia-2.farid-hajji.net> References: <4AFDF0AF.1090201@FreeBSD.org> <4AFEF726.2010200@FreeBSD.org> <20091114201645.GA56393@epia-2.farid-hajji.net> Message-ID: Well, reference machine doesn't even run FreeBSD. I need to mirror src (say, checkout of RELENG_8). Another problem is that only rsync may be used on the reference machine. :) 2009/11/14 cpghost > On Sat, Nov 14, 2009 at 09:38:11PM +0300, Nikolay Tychina wrote: > > Having a mirror accessible from our network for free would help users to > get > > sources for free. > > Incoming traffic from Internet costs money, that's problem. > > So you need to mirror /usr/src, and not the whole repository with > all its history, right? > > What I do here is to csup /usr/src on one reference machine every now > and then, and then distribute that directory with rsync to all other > 500+ machines inside. > > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ > From freebsd at jdc.parodius.com Sat Nov 14 20:49:42 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Sat Nov 14 20:49:49 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: References: <4AFDF0AF.1090201@FreeBSD.org> <4AFEF726.2010200@FreeBSD.org> <20091114201645.GA56393@epia-2.farid-hajji.net> Message-ID: <20091114204939.GA16087@icarus.home.lan> On Sat, Nov 14, 2009 at 11:39:03PM +0300, Nikolay Tychina wrote: > Well, reference machine doesn't even run FreeBSD. I need to mirror src (say, > checkout of RELENG_8). > Another problem is that only rsync may be used on the reference machine. :) Your best best, in my opinion, would be to work with the responsible party for said limitations and try to get them to understand that cvsup should be used in this case. If firewall holes are of a concern, state all that's needed is a single outbound (not inbound) permit rule be placed for TCP port 5999. As long as the non-FreeBSD box runs some form of *IX, you should be able to build cvsup and run it there. Otherwise, if such truly can't be done, possibly the conversation should be moved to freebsd-hubs where cvsup server owners reside and can comment on which ones offer rsync access, etc.. Yes, some of them do run an rsync daemon, but it's not a requirement. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From 000.fbsd at quip.cz Sat Nov 14 20:50:11 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sat Nov 14 20:50:17 2009 Subject: Curiously unable to access network - bce, 7.2-RELEASE on a HP blade server In-Reply-To: References: Message-ID: <4AFF17FF.9020802@quip.cz> Ivan Voras wrote: > I forgot to attach hardware details: > > bce0: HP NC373i Multifunction Gigabit Server Adapter (B2) ASIC > 0x57081021 Rev B2 B/C 0x04040105 Flags 2.5G > > Additional data point: I cannot reconfigure the card to 100 Mbit > operation (currently in 1000baseSX autoselect, full-duplex). > > Ivan Voras wrote: >> The symptoms are: >> >> * The device (bce0, bce1) comes up, is visible in ifconfig, can be >> configured, is UP and RUNNING, everything looks fine >> * Apparently, it simply doesn't work - no ping responses, TCP, nothing >> * But tcpdump shows that the NIC apparently does receive multicast >> router announcements, and some broadcast ARP traffic; only unicast >> seems to be affected. >> * Running "netstat 1" shows that apparently there are some packets >> received - once a second or so, and the "err" counters are 0. >> * Digging further, the dev.bce.0.stat_IfinFramesL2FilterDiscards >> contains an increasing number, currently arround 57000 and the >> dev.bce.0.stat_IfHCInBadOctets also contains an increasing number, >> currently around 450,000, while ...InOctets is around 30,000 and >> ...OutBadOctets is 0. >> >> From the sysctls it looks like maybe it's discarding valid input >> packets. I've tried disabling rxcsum, txcsum and TSO without effect. >> >> I cannot upgrade or install 8.0 because newusb has some problems with >> the hardware. >> >> Any ideas? Can it be related to this PR 134788? http://www.freebsd.org/cgi/query-pr.cgi?pr=134788 (your problem sounds different, but anyway you can try 7-STABLE bce driver) Recent changes in bce driver fixed it for me. Miroslav Lachman From ivoras at freebsd.org Sat Nov 14 20:57:55 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Nov 14 20:58:02 2009 Subject: Curiously unable to access network - bce, 7.2-RELEASE on a HP blade server In-Reply-To: <4AFF17FF.9020802@quip.cz> References: <4AFF17FF.9020802@quip.cz> Message-ID: <9bbcef730911141257w4d7b7f1tc3fb18c5bdcfe57a@mail.gmail.com> 2009/11/14 Miroslav Lachman <000.fbsd@quip.cz>: > Ivan Voras wrote: >> >> I forgot to attach hardware details: >> >> bce0: HP NC373i Multifunction Gigabit Server Adapter (B2) ASIC >> 0x57081021 Rev B2 B/C 0x04040105 Flags 2.5G >> >> Additional data point: I cannot reconfigure the card to 100 Mbit >> operation (currently in 1000baseSX autoselect, full-duplex). >> >> Ivan Voras wrote: >>> >>> The symptoms are: >>> >>> * The device (bce0, bce1) comes up, is visible in ifconfig, can be >>> configured, is UP and RUNNING, everything looks fine >>> * Apparently, it simply doesn't work - no ping responses, TCP, nothing >>> * But tcpdump shows that the NIC apparently does receive multicast >>> router announcements, and some broadcast ARP traffic; only unicast >>> seems to be affected. >>> * Running "netstat 1" shows that apparently there are some packets >>> received - once a second or so, and the "err" counters are 0. >>> * Digging further, the dev.bce.0.stat_IfinFramesL2FilterDiscards >>> contains an increasing number, currently arround 57000 and the >>> dev.bce.0.stat_IfHCInBadOctets also contains an increasing number, >>> currently around 450,000, while ...InOctets is around 30,000 and >>> ...OutBadOctets is 0. >>> >>> From the sysctls it looks like maybe it's discarding valid input >>> packets. I've tried disabling rxcsum, txcsum and TSO without effect. >>> >>> I cannot upgrade or install 8.0 because newusb has some problems with >>> the hardware. >>> >>> Any ideas? > > Can it be related to this PR 134788? > http://www.freebsd.org/cgi/query-pr.cgi?pr=134788 > (your problem sounds different, but anyway you can try 7-STABLE bce driver) > > Recent changes in bce driver fixed it for me. I did try booting 8.0 and found the same problem (though I cannot install 8.0 because of an unrelated problem with newusb). Judging by the dates in the PR, the fix should also be present in 8. From stb at lassitu.de Sat Nov 14 22:43:08 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sat Nov 14 22:43:16 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200910281112.06300.doconnor@gsoft.com.au> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> Message-ID: <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> Am 28.10.2009 um 01:41 schrieb Daniel O'Connor: > On Wed, 28 Oct 2009, jfarmer@goldsword.com wrote: >> Check the archives for stable@ and fs@. I believe that there was a >> thread not that long ago detailing exactly how to do that. IIRC, >> while it took a bit of work, it wasn't difficult. > > Hmm do you have any idea what the subject was? I'm having trouble > finding it :( If you still need it, it was "ZFS pool corrupted on upgrade of -current (probably sata renaming)" on -current back in July. You probably need to read the full thread, and there are some caveats, but it's sometimes possible to glabel each device/partion, and zpool replace the original device/partition with the labelled one online. HTH, STefan -- Stefan Bethke Fon +49 151 14070811 From cpghost at cordula.ws Sat Nov 14 23:37:59 2009 From: cpghost at cordula.ws (cpghost) Date: Sat Nov 14 23:38:06 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: References: <4AFDF0AF.1090201@FreeBSD.org> <4AFEF726.2010200@FreeBSD.org> <20091114201645.GA56393@epia-2.farid-hajji.net> Message-ID: <20091114233755.GA56782@epia-2.farid-hajji.net> On Sat, Nov 14, 2009 at 11:39:03PM +0300, Nikolay Tychina wrote: > Well, reference machine doesn't even run FreeBSD. I need to mirror > src (say, checkout of RELENG_8). According to /usr/src/contrib/csup/README, csup can run on Linux or other Unixoids too: Csup should build and run fine under any *BSD OS (that includes FreeBSD, NetBSD, OpenBSD and DragonFlyBSD), as well as Linux and Darwin. If you have a problem building from source, drop me a mail! So the reference machine running csup doesn't even need to run FreeBSD. :-) > Another problem is that only rsync may be used on the reference machine. :) If you're referring to firewall rules: csup connects by default to TCP port 5999 of the csup server(s). This is an outbound connection only, as there is no need to punch a hole in the firewall to allow for incoming connections. Maybe talking to your network admin would resolve the problem? Alternatively, there may be someone running a rsync daemon (over ssh?) who could provide you with /usr/src? Or there may be someone running a cvsup daemon on rsync's or http's port, so you could punch right through your firewall with csup -p 873 or csup -p 80 (or something similar)? -cpghost. -- Cordula's Web. http://www.cordula.ws/ From doconnor at gsoft.com.au Sat Nov 14 23:44:07 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat Nov 14 23:44:15 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> Message-ID: <4AFF40B1.3040705@gsoft.com.au> Stefan Bethke wrote: > Am 28.10.2009 um 01:41 schrieb Daniel O'Connor: > >> On Wed, 28 Oct 2009, jfarmer@goldsword.com wrote: >>> Check the archives for stable@ and fs@. I believe that there was a >>> thread not that long ago detailing exactly how to do that. IIRC, >>> while it took a bit of work, it wasn't difficult. >> Hmm do you have any idea what the subject was? I'm having trouble >> finding it :( > > If you still need it, it was "ZFS pool corrupted on upgrade of -current (probably sata renaming)" on -current back in July. You probably need to read the full thread, and there are some caveats, but it's sometimes possible to glabel each device/partion, and zpool replace the original device/partition with the labelled one online. It's here.. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html Quote... > On Wed Jul 15 at 16:22, Freddie Cash wrote: > Yep. It's as simple as: > > * label all the drives using glabel, while they're still attached to > the pool > * use "zpool replace pool ad4 label/disk01" to replace 1 drive > * wait for it to resilver > * use "zpool replace pool ad6 label/disk02" to replace the next > drive > * repeat the resilver and replace until all the devices are replaced > > This is what I did to one of our servers. Works quite nicely. > > There's no need to detach anything. I'll try it when I get home and see how it goes. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From doconnor at gsoft.com.au Sat Nov 14 23:49:52 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat Nov 14 23:50:00 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <4AFF40B1.3040705@gsoft.com.au> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> Message-ID: <4AFF4211.3040206@gsoft.com.au> Daniel O'Connor wrote: > Stefan Bethke wrote: >> Am 28.10.2009 um 01:41 schrieb Daniel O'Connor: >> >>> On Wed, 28 Oct 2009, jfarmer@goldsword.com wrote: >>>> Check the archives for stable@ and fs@. I believe that there was a >>>> thread not that long ago detailing exactly how to do that. IIRC, >>>> while it took a bit of work, it wasn't difficult. >>> Hmm do you have any idea what the subject was? I'm having trouble >>> finding it :( >> >> If you still need it, it was "ZFS pool corrupted on upgrade of >> -current (probably sata renaming)" on -current back in July. You >> probably need to read the full thread, and there are some caveats, but >> it's sometimes possible to glabel each device/partion, and zpool >> replace the original device/partition with the labelled one online. > > It's here.. > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html > > Quote... > > On Wed Jul 15 at 16:22, Freddie Cash wrote: > > Yep. It's as simple as: > > > > * label all the drives using glabel, while they're still attached to > > the pool > > * use "zpool replace pool ad4 label/disk01" to replace 1 drive > > * wait for it to resilver > > * use "zpool replace pool ad6 label/disk02" to replace the next > > drive > > * repeat the resilver and replace until all the devices are replaced > > > > This is what I did to one of our servers. Works quite nicely. > > > > There's no need to detach anything. > > I'll try it when I get home and see how it goes. It would be nice if the man page mentioned this case though, currently the "zpool replace" entry covers the case where the new disk has the same device node. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From ler at lerctr.org Sat Nov 14 23:59:01 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sat Nov 14 23:59:09 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <4AFF40B1.3040705@gsoft.com.au> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> Message-ID: <2aed0fc0af06c5fb17495e8925214ac7.squirrel@webmail.lerctr.org> On Sat, November 14, 2009 5:43 pm, Daniel O'Connor wrote: > Stefan Bethke wrote: >> Am 28.10.2009 um 01:41 schrieb Daniel O'Connor: >> >>> On Wed, 28 Oct 2009, jfarmer@goldsword.com wrote: >>>> Check the archives for stable@ and fs@. I believe that there was a >>>> thread not that long ago detailing exactly how to do that. IIRC, >>>> while it took a bit of work, it wasn't difficult. >>> Hmm do you have any idea what the subject was? I'm having trouble >>> finding it :( >> >> If you still need it, it was "ZFS pool corrupted on upgrade of -current >> (probably sata renaming)" on -current back in July. You probably need >> to read the full thread, and there are some caveats, but it's sometimes >> possible to glabel each device/partion, and zpool replace the original >> device/partition with the labelled one online. > > It's here.. > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html > > Quote... > > On Wed Jul 15 at 16:22, Freddie Cash wrote: > > Yep. It's as simple as: > > > > * label all the drives using glabel, while they're still attached to > > the pool > > * use "zpool replace pool ad4 label/disk01" to replace 1 drive > > * wait for it to resilver > > * use "zpool replace pool ad6 label/disk02" to replace the next > > drive > > * repeat the resilver and replace until all the devices are replaced > > > > This is what I did to one of our servers. Works quite nicely. > > > > There's no need to detach anything. > > I'll try it when I get home and see how it goes. When I try that, I get: # zpool status pool: vault state: ONLINE scrub: scrub completed after 3h4m with 0 errors on Wed Nov 11 04:32:00 2009 config: NAME STATE READ WRITE CKSUM vault ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada0s1f ONLINE 0 0 0 ada0s1e ONLINE 0 0 0 ada0s1d ONLINE 0 0 0 errors: No known data errors # glabel label disk01 /dev/ada1 glabel: Can't store metadata on /dev/ada1: Operation not permitted. # Ideas? > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From doconnor at gsoft.com.au Sun Nov 15 00:03:54 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sun Nov 15 00:04:01 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <2aed0fc0af06c5fb17495e8925214ac7.squirrel@webmail.lerctr.org> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> <2aed0fc0af06c5fb17495e8925214ac7.squirrel@webmail.lerctr.org> Message-ID: <4AFF455A.90001@gsoft.com.au> Larry Rosenman wrote: > NAME STATE READ WRITE CKSUM > vault ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > ada4 ONLINE 0 0 0 > ada5 ONLINE 0 0 0 > ada0s1f ONLINE 0 0 0 > ada0s1e ONLINE 0 0 0 > ada0s1d ONLINE 0 0 0 > > errors: No known data errors > # glabel label disk01 /dev/ada1 > glabel: Can't store metadata on /dev/ada1: Operation not permitted. > # > > Ideas? This is because glabel writes to the end of the disk (which is what it uses to persist the label), if you haven't already labelled them it can't add a one without destroying some data. I don't have this problem because I used GPT as a container and it has a UUID for each partition made. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From ler at lerctr.org Sun Nov 15 00:11:02 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sun Nov 15 00:11:10 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <4AFF455A.90001@gsoft.com.au> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> <2aed0fc0af06c5fb17495e8925214ac7.squirrel@webmail.lerctr.org> <4AFF455A.90001@gsoft.com.au> Message-ID: On Sat, November 14, 2009 6:03 pm, Daniel O'Connor wrote: > Larry Rosenman wrote: >> NAME STATE READ WRITE CKSUM >> vault ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> ada1 ONLINE 0 0 0 >> ada2 ONLINE 0 0 0 >> ada3 ONLINE 0 0 0 >> ada4 ONLINE 0 0 0 >> ada5 ONLINE 0 0 0 >> ada0s1f ONLINE 0 0 0 >> ada0s1e ONLINE 0 0 0 >> ada0s1d ONLINE 0 0 0 >> >> errors: No known data errors >> # glabel label disk01 /dev/ada1 >> glabel: Can't store metadata on /dev/ada1: Operation not permitted. >> # >> >> Ideas? > > This is because glabel writes to the end of the disk (which is what it > uses to persist the label), if you haven't already labelled them it > can't add a one without destroying some data. > > I don't have this problem because I used GPT as a container and it has a > UUID for each partition made. That makes sense. I guess if I ever rebuild this one, I'll be better about it :) and, now that we have raidz boot, I'll just make the whole mess ZFS. :) LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From stb at lassitu.de Sun Nov 15 00:14:39 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sun Nov 15 00:14:47 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <2aed0fc0af06c5fb17495e8925214ac7.squirrel@webmail.lerctr.org> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> <2aed0fc0af06c5fb17495e8925214ac7.squirrel@webmail.lerctr.org> Message-ID: <1A7FA148-8F7D-43DB-B28B-5346004C4F45@lassitu.de> Am 15.11.2009 um 00:58 schrieb Larry Rosenman: >>> On Wed Jul 15 at 16:22, Freddie Cash wrote: >>> Yep. It's as simple as: >>> >>> * label all the drives using glabel, while they're still attached to >>> the pool >>> * use "zpool replace pool ad4 label/disk01" to replace 1 drive >>> * wait for it to resilver >>> * use "zpool replace pool ad6 label/disk02" to replace the next >>> drive >>> * repeat the resilver and replace until all the devices are replaced >>> >>> This is what I did to one of our servers. Works quite nicely. >>> >>> There's no need to detach anything. >> >> I'll try it when I get home and see how it goes. > > When I try that, I get: > # glabel label disk01 /dev/ada1 > glabel: Can't store metadata on /dev/ada1: Operation not permitted. There's some caveats that you need to consider before attempting this: most importantly, glabel will re-use the last block of the disk/partition to store the label. Apparently, in many cases, the filesystem (UFS, ZFS) allocates blocks in larger chunks (8K or larger), and the last few blocks are unused and can be repurposed. But there's no guarantee, so you might damage the filesystem by labeling the device. I don't understand enough to definitivly say how to deterime whether the last block is available or not, so make sure you have a backup before trying. Secondly, my limited experience shows that both GEOM and ZFS can get confused about devices/partitions/geoms that start on the same block as others. How these are picked up by GEOM and/or ZFS in their probing depends on the order, and it wasn't always obvious to me how that worked. In one case, I couldn't get GEOM to pick up the /dev/label entry, since it removed the label entry as soon as the physical device node was probed. I've since come to the conclusion that labelled GPT partitions are the way forward, and now that booting off ZRAID pools on GPT partitions works, there's little speaking against it, IMO. Finally, if you want to label the existing disks, you probably need to take the pool offline for the labelling step, using zpool export, so the devices are not mounted anymore. Stefan -- Stefan Bethke Fon +49 151 14070811 From stb at lassitu.de Sun Nov 15 00:17:06 2009 From: stb at lassitu.de (Stefan Bethke) Date: Sun Nov 15 00:17:16 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <4AFF4211.3040206@gsoft.com.au> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> <200910281112.06300.doconnor@gsoft.com.au> <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> <4AFF4211.3040206@gsoft.com.au> Message-ID: Am 15.11.2009 um 00:49 schrieb Daniel O'Connor: > It would be nice if the man page mentioned this case though, currently the "zpool replace" entry covers the case where the new disk has the same device node. Huh? > zpool replace [?f] pool old_device [new_device] > > Replaces old_device with new_device. This is equivalent to attach? > ing new_device, waiting for it to resilver, and then detaching > old_device. Stefan -- Stefan Bethke Fon +49 151 14070811 From dougb at FreeBSD.org Sun Nov 15 02:19:15 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Nov 15 02:19:22 2009 Subject: how to mirror cvs or svn with rsync In-Reply-To: References: <4AFDF0AF.1090201@FreeBSD.org> <4AFEF726.2010200@FreeBSD.org> <20091114201645.GA56393@epia-2.farid-hajji.net> Message-ID: <4AFF652A.5060609@FreeBSD.org> Nikolay Tychina wrote: > Well, reference machine doesn't even run FreeBSD. I need to mirror src (say, > checkout of RELENG_8). > Another problem is that only rsync may be used on the reference machine. :) I really don't want to sound like a nag but you're still not being very clear as to what you're trying to do. Do you need to have just the checked out versions of /usr/src for one particular branch at one specific point in time that will be the same for all the machines that have to access it? If so, you'll need to check the files out on the reference machine. This can be done with cvsup, csup, or subversion (svn). If the reference machine is not running freebsd then svn is your worst option since in order to expand the $FreeBSD$ Id tags you need a patch to the subversion sources that a linux admin is not likely to look kindly on. You can likely find cvsup binaries for linux available on line, or you should be able to compile csup on the linux box. If compiling it doesn't work, report the problems on freebsd-hackers@freebsd.org. If it's genuinely not possible to run anything but rsync on the reference machine you'll have to check out the sources on a freebsd box and rsync the files to the reference machine from there. If this isn't what you're trying to accomplish at all you need to provide a lot more information about what you're trying to do. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From bf1783 at googlemail.com Sun Nov 15 03:18:59 2009 From: bf1783 at googlemail.com (b. f.) Date: Sun Nov 15 03:19:06 2009 Subject: how to mirror cvs or svn with rsync Message-ID: >I need a mirror of FreeBSD sources. >But the only one tool I can use for mirroring is rsync. I'm not quite sure why this is so: I wonder if you have examined all of your options, as others have written. Anyway, if you want to use rsync, have you tried any of the servers listed in: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-rsync.html ? From freebsd at abv.bg Sun Nov 15 09:53:12 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Sun Nov 15 09:53:28 2009 Subject: diskless - NFS root mount problem Message-ID: <1349537904.141314.1258277669303.JavaMail.apache@mail51.abv.bg> Hi, I'm trying to setup diskless operation between my FreeBSD desktop (server) and my laptop (client) I have NFS_ROOT and all other necessary options compiled into my kernel, I have this in /etc/exports: ========================================================================== / -ro -maproot=root -alldirs 192.168.0.3 /usr -ro -alldirs 192.168.0.3 ========================================================================== and this in dhcpd.conf ========================================================================== subnet 192.168.0.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.0.255; option routers 192.168.0.1; host laptop { hardware ethernet 00:1E:68:45:0D:98; fixed-address 192.168.0.3; filename "pxeboot"; option root-path "192.168.0.1:/"; } ========================================================================== when I attempt to (diskless) boot the laptop - stage one and two of the boot process are fine...actually stage tree which is the kernel is also fine...the kernel boots and starts bringing the system up...however it's unable to mount the NFS root for some reason and the system freezes here: ========================================================================== ... ... Trying to mount root from ufs:/dev/ad4s1a Trying to mount root from nfs: NFS ROOT: 192.168.0.1:/ nfs send error 13 for server 192.168.0.1:/ bge0: link state changed to DOWN bge0: link state changed to UP ========================================================================== I think error 13 means attempt to write on read-only mounted NFS...but it does not make sense, does it? do you have any ideas what could be the problem? thanks ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From t at gransee.dk Sun Nov 15 14:46:48 2009 From: t at gransee.dk (Tomas G) Date: Sun Nov 15 14:46:56 2009 Subject: FreeBSD jails in the Asia region Message-ID: <9BE2333E6A7A4956A1FD5CC2872338DC@tomaslaptop> Hello, I am trying to find a hosting provider that sells FreeBSD jails in the Asia region. I would prefer both v4 and v6 connectivity, but that is not a requirement. I need full root access to the jail, similar to what JohnCompanies and RootBSD are offering, only in Asia. Any recommendations ? I would prefer a jail since they are usually cheaper than a full-blown server, but if anyone can recommend affordable alternatives I am listening. I would prefer a recent FreeBSD version, like 7.x. Thank you in advance! Best regards, Tomas PS. My apologies if this is the incorrect forum for this question. From jhs at berklix.com Sun Nov 15 17:12:31 2009 From: jhs at berklix.com (Julian H. Stacey) Date: Sun Nov 15 17:12:38 2009 Subject: FreeBSD jails in the Asia region In-Reply-To: Your message "Sun, 15 Nov 2009 15:27:15 +0100." <9BE2333E6A7A4956A1FD5CC2872338DC@tomaslaptop> Message-ID: <200911151712.nAFHCBSa038212@fire.js.berklix.net> Hi, Reference: > From: "Tomas G" > Date: Sun, 15 Nov 2009 15:27:15 +0100 > Message-id: <9BE2333E6A7A4956A1FD5CC2872338DC@tomaslaptop> "Tomas G" wrote: > Hello, > > I am trying to find a hosting provider that sells FreeBSD jails > in the Asia region. I would prefer both v4 and v6 connectivity, > but that is not a requirement. I need full root access to the > jail, similar to what JohnCompanies and RootBSD are offering, > only in Asia. Any recommendations ? > I would prefer a jail since they are usually cheaper than a > full-blown server, but if anyone can recommend affordable > alternatives I am listening. I would prefer a recent FreeBSD > version, like 7.x. > > Thank you in advance! > > Best regards, > Tomas > > PS. My apologies if this is the incorrect forum for this question. See http://www.freebsd.org/commercial/isp.html If nothing there try asking on list freebsd-isp@freebsd.org Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org From dnelson at allantgroup.com Sun Nov 15 17:47:24 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Sun Nov 15 17:47:32 2009 Subject: (MORE INFO) Ext firewire drive not mounted after update In-Reply-To: <20091113161220.18454229@hp> References: <20091113130147.744521d7@asus64> <20091113145015.647955b9@asus64> <20091113231539.GN89052@dan.emsphone.com> <20091113161220.18454229@hp> Message-ID: <20091115174718.GA89004@dan.emsphone.com> In the last episode (Nov 13), Robert said: > On Fri, 13 Nov 2009 17:15:39 -0600 Dan Nelson wrote: > > In the last episode (Nov 13), Robert said: > > > On Fri, 13 Nov 2009 13:01:47 -0800 > > > Robert wrote: > > > It appears that some thing is amiss with the latest version. I will > > > download the latest livefs iso and see if that works. > > > > I think I remember seing a posting within the last few days saying that > > the "sbp" device wan't going to be compiled into the 8.0-release kernel > > due to it causing hangs on boot. If you run "kldload sbp" as root after > > the system has booted you should see your disk devices appear. > > Thanks for responding. I checked and the "sbp" device is in fact commented > out. I do remember a thread a month or two back about some folkes having > trouble with firewire drives. I never experienced any trouble on of that > trouble on this system. > > I can continue to operate my drive on USB but I may need firewire in the > near future. I have a friend who is a photographer and I archive her > photos for her. She sends me an external drive or two and I burn her > projects onto DVD. I am not sure if her drives have an USB connector. Note that you can still run "kldload sbp" after bootup to see fireware disks. You can also try adding "device sbp" back to your kernel config and see if it works for you. The hangs apparently only happen on certain motherboards. -- Dan Nelson dnelson@allantgroup.com From ler at lerctr.org Sun Nov 15 18:37:26 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sun Nov 15 18:37:34 2009 Subject: RELENG_7: Kernel Compile Failure Message-ID: <175fd45439c7cf285eb894361ae58e5a.squirrel@webmail.lerctr.org> Just csup'd off cvsup17.us.freebsd.org: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/kern/kern_conf.c /usr/src/sys/kern/kern_conf.c: In function 'giant_mmap': /usr/src/sys/kern/kern_conf.c:483: error: 'D_MMAP2' undeclared (first use in this function) /usr/src/sys/kern/kern_conf.c:483: error: (Each undeclared identifier is reported only once /usr/src/sys/kern/kern_conf.c:483: error: for each function it appears in.) /usr/src/sys/kern/kern_conf.c:484: error: 'struct cdevsw' has no member named 'd_mmap2' /usr/src/sys/kern/kern_conf.c: In function 'prep_cdevsw': /usr/src/sys/kern/kern_conf.c:677: error: 'D_MMAP2' undeclared (first use in this function) /usr/src/sys/kern/kern_conf.c:698: error: 'struct cdevsw' has no member named 'd_mmap2' /usr/src/sys/kern/kern_conf.c:698: error: 'struct cdevsw' has no member named 'd_mmap2' /usr/src/sys/kern/kern_conf.c:698: error: 'd_mmap2_t' undeclared (first use in this function) /usr/src/sys/kern/kern_conf.c:698: error: expected expression before ')' token /usr/src/sys/kern/kern_conf.c:698: error: 'struct cdevsw' has no member named 'd_mmap2' *** Error code 1 Stop in /usr/obj/usr/src/sys/THEBIGHONKER. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # Ideas? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From ler at lerctr.org Sun Nov 15 19:15:53 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sun Nov 15 19:16:01 2009 Subject: RELENG_7: Kernel Compile Failure In-Reply-To: <20091115191039.GV1649@albert.catwhisker.org> References: <175fd45439c7cf285eb894361ae58e5a.squirrel@webmail.lerctr.org> <20091115191039.GV1649@albert.catwhisker.org> Message-ID: <8cd25834fbad3a9327a6dde9a7697deb.squirrel@webmail.lerctr.org> On Sun, November 15, 2009 1:10 pm, David Wolfskill wrote: > On Sun, Nov 15, 2009 at 12:37:23PM -0600, Larry Rosenman wrote: >> ... >> /usr/src/sys/kern/kern_conf.c:698: error: 'struct cdevsw' has no member >> named 'd_mmap2' >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/THEBIGHONKER. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> # >> >> >> Ideas? >> ... > > Try a different mirror, perhaps? I've had no problems tracking stable/7 > daily (though I'm using SVN). Thanks. Pulled a update from cvsup5.us.freebsd.org, and changes were picked up. Can someone check the health of cvsup17.us.freebsd.org? > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From freebsd at abv.bg Sun Nov 15 21:47:12 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Sun Nov 15 21:47:19 2009 Subject: diskless - NFS root mount problem Message-ID: <120653617.10492.1258321630563.JavaMail.apache@mail53.abv.bg> Hi Tim, thanks a lot for your answer, I'll try that out tomorrow. cheers, mgp > > >Please compare my working configuration to yours to check. I found >lots of odd problems in your post and I thought it'd be best to just >run with this clean slate. > >Network config: > One low-power PC Engines ALIX board running as the NFS server, with >a microdrive partitioned off for it's own system, plus a separate >mounted partition for diskless clients. This config works best with >one diskless client, and is not the documented way from FreeBSD >handbook to accomplish diskless workstations. I'll note what I >immediately saw as an error in your config during these snippets. > >alix# bsdlabel /dev/ad0s1 ># /dev/ad0s1: >8 partitions: ># size offset fstype [fsize bsize bps/cpg] > a: 1048576 16 4.2BSD 2048 16384 8 > c: 12000177 0 unused 0 0 # "raw" part, don't edit > h: 10951585 1048592 4.2BSD 2048 16384 28552 > >alix# cat /etc/fstab >/dev/ad0s1a / ufs rw 0 0 >/dev/ad0s1h /diskless ufs rw 0 0 > >alix# cat /etc/exports >/diskless -maproot=0:0 -network 192.168.0.0 -mask 255.255.255.0 > >*** maproot needs a user and group definition. > >alix# cat /etc/rc.conf >rpcbind_enable="YES" >nfs_server_enable="YES" >rpc_statd_enable="YES" >rpc_lockd_enable="YES" > >*** rpc_lockd provides file locking, rpc_lockd depends on rpc_statd > > >************** Diskless side > >*** I believe the root filesystem information is passed on from dhcp, >to pxeboot, to the kernel, in order to mount the root filesystem. You >can have a 0-size fstab file for read-write access, or provide the >read-only nfs root here. If you want it read only, it's best to >specify it here, such as below > >alix# cat /diskless/etc/fstab >192.168.0.1:/diskless / nfs ro 0 0 > >alix# cat /diskless/etc/rc.conf >rpcbind_enable="YES" >nfs_client_enable="YES" >rpc_statd_enable="YES" >rpc_lockd_enable="YES" > >*** File locking needed lockd/statd support on the client, also. >Think of editing /etc/passwd (the proper way) when you need file >locking. > > > > >This will result in a basic, 1-workstation diskless setup working. >The difference is that the FreeBSD rc startup looks for a /conf >directory which can provide multiple overrides to multiple >workstations. I tried setting up a livecd with a /conf directory only >to find that the /conf is checked, no matter which medium it's booting >off of. > >This config does NOT cover the DHCP scope, TFTP, IPs or other settings >that might be pertinent to booting diskless-ly. > >Note that by sharing your exact / filesystem as an export is a bad >idea. It will essentially create a NFS server on a NFS server round >robin and probably won't connect. It's why you setup a separate >partition (EVEN if it's a file-backed filesystem mounted with the help >of mdconfig on a separate mountpoint on your filesystem). > >Once you revise your config, please try again. > > >--Tim > ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From tajudd at gmail.com Sun Nov 15 22:03:21 2009 From: tajudd at gmail.com (Tim Judd) Date: Sun Nov 15 22:03:28 2009 Subject: diskless - NFS root mount problem In-Reply-To: <1349537904.141314.1258277669303.JavaMail.apache@mail51.abv.bg> References: <1349537904.141314.1258277669303.JavaMail.apache@mail51.abv.bg> Message-ID: Please compare my working configuration to yours to check. I found lots of odd problems in your post and I thought it'd be best to just run with this clean slate. Network config: One low-power PC Engines ALIX board running as the NFS server, with a microdrive partitioned off for it's own system, plus a separate mounted partition for diskless clients. This config works best with one diskless client, and is not the documented way from FreeBSD handbook to accomplish diskless workstations. I'll note what I immediately saw as an error in your config during these snippets. alix# bsdlabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 16 4.2BSD 2048 16384 8 c: 12000177 0 unused 0 0 # "raw" part, don't edit h: 10951585 1048592 4.2BSD 2048 16384 28552 alix# cat /etc/fstab /dev/ad0s1a / ufs rw 0 0 /dev/ad0s1h /diskless ufs rw 0 0 alix# cat /etc/exports /diskless -maproot=0:0 -network 192.168.0.0 -mask 255.255.255.0 *** maproot needs a user and group definition. alix# cat /etc/rc.conf rpcbind_enable="YES" nfs_server_enable="YES" rpc_statd_enable="YES" rpc_lockd_enable="YES" *** rpc_lockd provides file locking, rpc_lockd depends on rpc_statd ************** Diskless side *** I believe the root filesystem information is passed on from dhcp, to pxeboot, to the kernel, in order to mount the root filesystem. You can have a 0-size fstab file for read-write access, or provide the read-only nfs root here. If you want it read only, it's best to specify it here, such as below alix# cat /diskless/etc/fstab 192.168.0.1:/diskless / nfs ro 0 0 alix# cat /diskless/etc/rc.conf rpcbind_enable="YES" nfs_client_enable="YES" rpc_statd_enable="YES" rpc_lockd_enable="YES" *** File locking needed lockd/statd support on the client, also. Think of editing /etc/passwd (the proper way) when you need file locking. This will result in a basic, 1-workstation diskless setup working. The difference is that the FreeBSD rc startup looks for a /conf directory which can provide multiple overrides to multiple workstations. I tried setting up a livecd with a /conf directory only to find that the /conf is checked, no matter which medium it's booting off of. This config does NOT cover the DHCP scope, TFTP, IPs or other settings that might be pertinent to booting diskless-ly. Note that by sharing your exact / filesystem as an export is a bad idea. It will essentially create a NFS server on a NFS server round robin and probably won't connect. It's why you setup a separate partition (EVEN if it's a file-backed filesystem mounted with the help of mdconfig on a separate mountpoint on your filesystem). Once you revise your config, please try again. --Tim From freebsd at abv.bg Mon Nov 16 18:22:08 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Mon Nov 16 18:22:22 2009 Subject: diskless - NFS root mount problem Message-ID: <1827106023.12813.1258395733748.JavaMail.apache@mail53.abv.bg> Hi, thanks again for your response: here's what I have, what I do and what I want to happen 1. I have my desktop machine which is running FreeBSD-7.2-STABLE-amd64 from June. I created a new distribution like that (as shown in the handbook - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-diskless.html): ================================================================================ mkdir /storage0/diskless cd /usr/src export DESTDIR=/storage0/diskless make buildworld buildkernel installworld distribution installkernel ================================================================================ and created /storage0/diskless/etc/fstab with the following content: ================================================================================ 192.168.0.1:/storage0/diskless / nfs ro 0 0 ================================================================================ and I put this in /etc/exports (having in mind your advice about the group) ================================================================================ /storage0/diskless -maproot=0:0 -ro -alldirs 192.168.0.3 /usr -ro -alldirs 192.168.0.3 ================================================================================ and this is in my dhcpd.conf (I tried with and without the comments - no difference, same result) ================================================================================ host laptop { hardware ethernet 00:1E:68:45:0D:98; # option host-name "laptop"; # ddns-hostname "laptop"; # next-server 192.168.0.1; fixed-address 192.168.0.3; filename "pxeboot"; option root-path "192.168.0.1:/storage0/diskless"; } ================================================================================ 2. And I do this: ================================================================================ rpcbind nfsd -u -t -n 4 mountd -r /etc/rc.d/ineted onestart # I have my TFTP root set to /boot /usr/local/etc/rc.d/isc-dhcpd onestart ================================================================================ then I start my laptop (which has a 64bit CPU therefore it should be compatible with my amd64 kernel) enter the boot menu and choose the network boot option and I can see that it acquires its IP address then fetches pxeboot over TFTP then pxeboot loads the kernel and the kernel starts bringing the system up...and these are the last few lines where the system stops: ================================================================================ ... ... Trying to mount root from nfs:192.168.0.1:/storage0/diskless NFS ROOT: 192.168.0.1:/storage0/diskless nfs send error 13 for server 192.168.0.1:/storage0/diskless bge0: link state changed to DOWN bge0: link state changed to UP ================================================================================ 3. What I want is to have a server that multiple clients can boot from (diskless-ly as you say). And I want all file systems provided by the server to be read-only (which means I don't need lockd, do I...) Do you have an idea what could be my problem? ...obviously my TFTP and DHCP services are fine, even the NFS as pxeboot is able to download the kernel...maybe something in my distribution in /storage0/diskless is not OK? thanks mgp >Please compare my working configuration to yours to check. I found >lots of odd problems in your post and I thought it'd be best to just >run with this clean slate. > >Network config: > One low-power PC Engines ALIX board running as the NFS server, with >a microdrive partitioned off for it's own system, plus a separate >mounted partition for diskless clients. This config works best with >one diskless client, and is not the documented way from FreeBSD >handbook to accomplish diskless workstations. I'll note what I >immediately saw as an error in your config during these snippets. > >alix# bsdlabel /dev/ad0s1 ># /dev/ad0s1: >8 partitions: ># size offset fstype [fsize bsize bps/cpg] > a: 1048576 16 4.2BSD 2048 16384 8 > c: 12000177 0 unused 0 0 # "raw" part, don't edit > h: 10951585 1048592 4.2BSD 2048 16384 28552 > >alix# cat /etc/fstab >/dev/ad0s1a / ufs rw 0 0 >/dev/ad0s1h /diskless ufs rw 0 0 > >alix# cat /etc/exports >/diskless -maproot=0:0 -network 192.168.0.0 -mask 255.255.255.0 > >*** maproot needs a user and group definition. > >alix# cat /etc/rc.conf >rpcbind_enable="YES" >nfs_server_enable="YES" >rpc_statd_enable="YES" >rpc_lockd_enable="YES" > >*** rpc_lockd provides file locking, rpc_lockd depends on rpc_statd > > >************** Diskless side > >*** I believe the root filesystem information is passed on from dhcp, >to pxeboot, to the kernel, in order to mount the root filesystem. You >can have a 0-size fstab file for read-write access, or provide the >read-only nfs root here. If you want it read only, it's best to >specify it here, such as below > >alix# cat /diskless/etc/fstab >192.168.0.1:/diskless / nfs ro 0 0 > >alix# cat /diskless/etc/rc.conf >rpcbind_enable="YES" >nfs_client_enable="YES" >rpc_statd_enable="YES" >rpc_lockd_enable="YES" > >*** File locking needed lockd/statd support on the client, also. >Think of editing /etc/passwd (the proper way) when you need file >locking. > > > > >This will result in a basic, 1-workstation diskless setup working. >The difference is that the FreeBSD rc startup looks for a /conf >directory which can provide multiple overrides to multiple >workstations. I tried setting up a livecd with a /conf directory only >to find that the /conf is checked, no matter which medium it's booting >off of. > >This config does NOT cover the DHCP scope, TFTP, IPs or other settings >that might be pertinent to booting diskless-ly. > >Note that by sharing your exact / filesystem as an export is a bad >idea. It will essentially create a NFS server on a NFS server round >robin and probably won't connect. It's why you setup a separate >partition (EVEN if it's a file-backed filesystem mounted with the help >of mdconfig on a separate mountpoint on your filesystem). > >Once you revise your config, please try again. > > >--Tim >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From petefrench at ticketswitch.com Mon Nov 16 18:24:49 2009 From: petefrench at ticketswitch.com (Pete French) Date: Mon Nov 16 18:24:56 2009 Subject: ZFS panic "solaris assert: sm->sm_space" loses pool on RELENG-7 Message-ID: Sometime on sunday our main server paniced with the following error: panic: solaris assert: sm->sm_space == space (0x5e45000 == 0x5e45600), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 361 I did some goolging and found a couple of refereces to other people who have seen this. Both of them, however, could not recover the pool and needed to restore all the data from backups (which I am in the process of). Soes anyone know anything more about this ? Specificly if it a known rpoblem which is fixed in 8.0 ? I couldn't find a PR of any kind, but the fact that a machine can spontaneously loose all it's data from a set of filesystems worries me greatly. cheers, -pete. From traveling08 at cox.net Mon Nov 16 19:01:20 2009 From: traveling08 at cox.net (Robert) Date: Mon Nov 16 19:01:27 2009 Subject: (MORE INFO) Ext firewire drive not mounted after update In-Reply-To: <20091115174718.GA89004@dan.emsphone.com> References: <20091113130147.744521d7@asus64> <20091113145015.647955b9@asus64> <20091113231539.GN89052@dan.emsphone.com> <20091113161220.18454229@hp> <20091115174718.GA89004@dan.emsphone.com> Message-ID: <20091116110113.534c423c@hp> On Sun, 15 Nov 2009 11:47:20 -0600 Dan Nelson wrote: > > I can continue to operate my drive on USB but I may need firewire > > in the near future. I have a friend who is a photographer and I > > archive her photos for her. She sends me an external drive or two > > and I burn her projects onto DVD. I am not sure if her drives have > > an USB connector. > > Note that you can still run "kldload sbp" after bootup to see fireware > disks. You can also try adding "device sbp" back to your kernel > config and see if it works for you. The hangs apparently only happen > on certain motherboards. > Dan Last week I added sbp_load to /boot/loader.conf, reconnected the firewire cable to the external drive and rebooted. All is working fine. Thanks Robert From freebsd at abv.bg Mon Nov 16 19:47:30 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Mon Nov 16 19:47:37 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem Message-ID: <1913483789.15152.1258400853581.JavaMail.apache@mail53.abv.bg> Hi, it turned out I was stupid enough to misconfigure the kernel...I forgot that I had left the IPFIREWALL options turned on and as you know it's default to deny so once the kernel initializes ipfw it blocks everything including NFS so that was the whole problem...I removed the IPFIREWALL option and all went fine. thanks again mgp > Hi, >thanks again for your response: >here's what I have, what I do and what I want to happen > >1. I have my desktop machine which is running FreeBSD-7.2-STABLE-amd64 from June. > I created a new distribution like that (as shown in the handbook - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-diskless.html): > >================================================================================ >mkdir /storage0/diskless >cd /usr/src >export DESTDIR=/storage0/diskless >make buildworld buildkernel installworld distribution installkernel >================================================================================ > >and created /storage0/diskless/etc/fstab with the following content: > >================================================================================ >192.168.0.1:/storage0/diskless / nfs ro 0 0 >================================================================================ > >and I put this in /etc/exports (having in mind your advice about the group) > >================================================================================ >/storage0/diskless -maproot=0:0 -ro -alldirs 192.168.0.3 >/usr -ro -alldirs 192.168.0.3 >================================================================================ > >and this is in my dhcpd.conf (I tried with and without the comments - no difference, same result) > >================================================================================ > host laptop { > hardware ethernet 00:1E:68:45:0D:98; ># option host-name "laptop"; ># ddns-hostname "laptop"; ># next-server 192.168.0.1; > fixed-address 192.168.0.3; > filename "pxeboot"; > option root-path "192.168.0.1:/storage0/diskless"; > } >================================================================================ > >2. And I do this: > >================================================================================ >rpcbind >nfsd -u -t -n 4 >mountd -r >/etc/rc.d/ineted onestart # I have my TFTP root set to /boot >/usr/local/etc/rc.d/isc-dhcpd onestart >================================================================================ > >then I start my laptop (which has a 64bit CPU therefore it should be compatible with my amd64 kernel) enter the boot menu and choose the network boot option and I can see that it acquires its IP address then fetches pxeboot over TFTP then pxeboot loads the kernel and the kernel starts bringing the system up...and these are the last few lines where the system stops: > >================================================================================ >... >... >Trying to mount root from nfs:192.168.0.1:/storage0/diskless >NFS ROOT: 192.168.0.1:/storage0/diskless >nfs send error 13 for server 192.168.0.1:/storage0/diskless >bge0: link state changed to DOWN >bge0: link state changed to UP >================================================================================ > >3. What I want is to have a server that multiple clients can boot from (diskless-ly as you say). And I want all file systems provided by the server to be read-only (which means I don't need lockd, do I...) > >Do you have an idea what could be my problem? ...obviously my TFTP and DHCP services are fine, even the NFS as pxeboot is able to download the kernel...maybe something in my distribution in /storage0/diskless is not OK? > >thanks >mgp > > > >Please compare my working configuration to yours to check. I found > >lots of odd problems in your post and I thought it'd be best to just > >run with this clean slate. > > > >Network config: > > One low-power PC Engines ALIX board running as the NFS server, with > >a microdrive partitioned off for it's own system, plus a separate > >mounted partition for diskless clients. This config works best with > >one diskless client, and is not the documented way from FreeBSD > >handbook to accomplish diskless workstations. I'll note what I > >immediately saw as an error in your config during these snippets. > > > >alix# bsdlabel /dev/ad0s1 > ># /dev/ad0s1: > >8 partitions: > ># size offset fstype [fsize bsize bps/cpg] > > a: 1048576 16 4.2BSD 2048 16384 8 > > c: 12000177 0 unused 0 0 # "raw" part, don't edit > > h: 10951585 1048592 4.2BSD 2048 16384 28552 > > > >alix# cat /etc/fstab > >/dev/ad0s1a / ufs rw 0 0 > >/dev/ad0s1h /diskless ufs rw 0 0 > > > >alix# cat /etc/exports > >/diskless -maproot=0:0 -network 192.168.0.0 -mask 255.255.255.0 > > > >*** maproot needs a user and group definition. > > > >alix# cat /etc/rc.conf > >rpcbind_enable="YES" > >nfs_server_enable="YES" > >rpc_statd_enable="YES" > >rpc_lockd_enable="YES" > > > >*** rpc_lockd provides file locking, rpc_lockd depends on rpc_statd > > > > > >************** Diskless side > > > >*** I believe the root filesystem information is passed on from dhcp, > >to pxeboot, to the kernel, in order to mount the root filesystem. You > >can have a 0-size fstab file for read-write access, or provide the > >read-only nfs root here. If you want it read only, it's best to > >specify it here, such as below > > > >alix# cat /diskless/etc/fstab > >192.168.0.1:/diskless / nfs ro 0 0 > > > >alix# cat /diskless/etc/rc.conf > >rpcbind_enable="YES" > >nfs_client_enable="YES" > >rpc_statd_enable="YES" > >rpc_lockd_enable="YES" > > > >*** File locking needed lockd/statd support on the client, also. > >Think of editing /etc/passwd (the proper way) when you need file > >locking. > > > > > > > > > >This will result in a basic, 1-workstation diskless setup working. > >The difference is that the FreeBSD rc startup looks for a /conf > >directory which can provide multiple overrides to multiple > >workstations. I tried setting up a livecd with a /conf directory only > >to find that the /conf is checked, no matter which medium it's booting > >off of. > > > >This config does NOT cover the DHCP scope, TFTP, IPs or other settings > >that might be pertinent to booting diskless-ly. > > > >Note that by sharing your exact / filesystem as an export is a bad > >idea. It will essentially create a NFS server on a NFS server round > >robin and probably won't connect. It's why you setup a separate > >partition (EVEN if it's a file-backed filesystem mounted with the help > >of mdconfig on a separate mountpoint on your filesystem). > > > >Once you revise your config, please try again. > > > > > >--Tim > >_______________________________________________ > >freebsd-stable@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > >----------------------------------------------------------------- >????? ???????? ?????? ?? Vesti.bg! >http://www.vesti.bg >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From tajudd at gmail.com Mon Nov 16 21:03:30 2009 From: tajudd at gmail.com (Tim Judd) Date: Mon Nov 16 21:04:02 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem In-Reply-To: <1913483789.15152.1258400853581.JavaMail.apache@mail53.abv.bg> References: <1913483789.15152.1258400853581.JavaMail.apache@mail53.abv.bg> Message-ID: On 11/16/09, Mario Pavlov wrote: > Hi, > it turned out I was stupid enough to misconfigure the kernel...I forgot that > I had left the IPFIREWALL options turned on and as you know it's default to > deny so once the kernel initializes ipfw it blocks everything including NFS > so that was the whole problem...I removed the IPFIREWALL option and all went > fine. > Ah, one of those moments. I have them too. Good to know it's working for you, and I would just because I'm the perfectionist personality type, change a couple of things that won't make a negative impact. The server's exports has no reason to export the diskless root with -alldirs. The system isn't asking for any mountpoint within / so you can leave off the -alldirs. 2nd, you buildworld and installworld into the diskless root, but never use it. You're using disk space you can reclaim. > thanks again > mgp Glad it's working, enjoy! From dougb at FreeBSD.org Mon Nov 16 21:32:18 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Nov 16 21:32:52 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem In-Reply-To: <1913483789.15152.1258400853581.JavaMail.apache@mail53.abv.bg> References: <1913483789.15152.1258400853581.JavaMail.apache@mail53.abv.bg> Message-ID: <4B01C4DF.4040400@FreeBSD.org> Mario Pavlov wrote: > Hi, it turned out I was stupid enough to misconfigure the > kernel...I forgot that I had left the IPFIREWALL options turned on You're not a real sysadmin until you've firewalled yourself out of at least one mission-critical system. Bonus points if it has no out-of-band control plane. Further bonus points if it is more than 100 miles away, and you are the one who has to drive to the data center. -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From marka at isc.org Mon Nov 16 23:12:00 2009 From: marka at isc.org (Mark Andrews) Date: Mon Nov 16 23:13:00 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem In-Reply-To: Your message of "Mon, 16 Nov 2009 13:32:15 -0800." <4B01C4DF.4040400@FreeBSD.org> References: <1913483789.15152.1258400853581.JavaMail.apache@mail53.abv.bg> <4B01C4DF.4040400@FreeBSD.org> Message-ID: <200911162311.nAGNBjBt023863@drugs.dv.isc.org> In message <4B01C4DF.4040400@FreeBSD.org>, Doug Barton writes: > Mario Pavlov wrote: > > Hi, it turned out I was stupid enough to misconfigure the > > kernel...I forgot that I had left the IPFIREWALL options turned on > > You're not a real sysadmin until you've firewalled yourself out of at > least one mission-critical system. > > Bonus points if it has no out-of-band control plane. > > Further bonus points if it is more than 100 miles away, and you are > the one who has to drive to the data center. Triple bonus points if it is +20 hours of flight time away. Home data center and angry wife w/o Internet access. Yes I managed to stuff up a home machine while in Ireland. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ade at FreeBSD.org Mon Nov 16 23:47:57 2009 From: ade at FreeBSD.org (Ade Lovett) Date: Mon Nov 16 23:48:05 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem In-Reply-To: <4B01C4DF.4040400@FreeBSD.org> References: <1913483789.15152.1258400853581.JavaMail.apache@mail53.abv.bg> <4B01C4DF.4040400@FreeBSD.org> Message-ID: <95B3B3E7-CEFF-43FE-9937-B4E2A7AA026C@FreeBSD.org> On Nov 16, 2009, at 13:32 , Doug Barton wrote: > You're not a real sysadmin until you've firewalled yourself out of at > least one mission-critical system. > > Bonus points if it has no out-of-band control plane. > > Further bonus points if it is more than 100 miles away, and you are > the one who has to drive to the data center. Extreme bonus points if said system is on another continent, and you have to get on a plane _right_now_ (spending the flight wondering why the OOB system is dead). -aDe From delphij at delphij.net Tue Nov 17 02:34:05 2009 From: delphij at delphij.net (Xin LI) Date: Tue Nov 17 02:34:12 2009 Subject: Softdep related panic: vm_fault: fault on nofault entry, addr: c1485000 Message-ID: <4B020B8D.7040006@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I got the following panics several times on 7.2-RELEASE-p4 system, have anyone aware of the issue? (Note that it always fault on c1485000, can this be a memory issue? [delphij@video] ~> grep ^panic info.* info.1:panic: vm_fault: fault on nofault entry, addr: c1485000 info.2:panic: vm_fault: fault on nofault entry, addr: c1485000 info.3:panic: vm_fault: fault on nofault entry, addr: c1485000 info.4:panic: vm_fault: fault on nofault entry, addr: c1485000) Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: c1485000 cpuid = 3 Uptime: 10d4h21m43s Physical memory: 2034 MB Dumping 275 MB: 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/accf_data.ko...Reading symbols from /boot/kernel/accf_data.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_data.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc07e25f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e28c9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a18068 in vm_fault (map=0xc1471000, vaddr=3242741760, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277 #4 0xc0ae414e in trap_pfault (frame=0xe5726af8, usermode=0, eva=3242745808) at /usr/src/sys/i386/i386/trap.c:841 #5 0xc0ae4b5c in trap (frame=0xe5726af8) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac926b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07d15b6 in free (addr=0xc57bc700, mtp=0xc0c6b380) at vm_page.h:266 #8 0xc09ec1a3 in workitem_free (item=0xc57bc700, type=Variable "type" is not available. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:641 #9 0xc09ec329 in handle_allocindir_partdone (aip=0xc57bc700) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4487 #10 0xc09f2d5f in softdep_disk_write_complete (bp=0xc52cfbb0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4312 #11 0xc084f006 in bufdone_finish (bp=0xc52cfbb0) at buf.h:443 #12 0xc084f47d in bufdone (bp=0xc52cfbb0) at /usr/src/sys/kern/vfs_bio.c:3177 #13 0xc078bfa8 in g_vfs_done (bip=0xc628a840) at /usr/src/sys/geom/geom_vfs.c:97 #14 0xc084957d in biodone (bp=0xc628a840) at /usr/src/sys/kern/vfs_bio.c:3013 #15 0xc078815f in g_io_schedule_up (tp=0xc54e1000) at /usr/src/sys/geom/geom_io.c:587 #16 0xc07884ae in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #17 0xc07bd0a9 in fork_exit (callout=0xc0788440 , arg=0x0, frame=0xe5726d38) at /usr/src/sys/kern/kern_fork.c:810 #18 0xc0ac92e0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksCC40ACgkQi+vbBBjt66Bs/QCfTf5UNkbSRo3PEEPcnC0GDIRl kcoAn1goCLS8RlfL97pu7lyjjzVF4vQM =jxSt -----END PGP SIGNATURE----- From delphij at delphij.net Tue Nov 17 02:34:14 2009 From: delphij at delphij.net (Xin LI) Date: Tue Nov 17 02:34:21 2009 Subject: Softdep related panic: vm_fault: fault on nofault entry, addr: c1485000 Message-ID: <4B020B98.1030003@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I got the following panics several times on 7.2-RELEASE-p4 system, have anyone aware of the issue? (Note that it always fault on c1485000, can this be a memory issue? [delphij@video] ~> grep ^panic info.* info.1:panic: vm_fault: fault on nofault entry, addr: c1485000 info.2:panic: vm_fault: fault on nofault entry, addr: c1485000 info.3:panic: vm_fault: fault on nofault entry, addr: c1485000 info.4:panic: vm_fault: fault on nofault entry, addr: c1485000) Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: c1485000 cpuid = 3 Uptime: 10d4h21m43s Physical memory: 2034 MB Dumping 275 MB: 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/accf_data.ko...Reading symbols from /boot/kernel/accf_data.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_data.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc07e25f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e28c9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a18068 in vm_fault (map=0xc1471000, vaddr=3242741760, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277 #4 0xc0ae414e in trap_pfault (frame=0xe5726af8, usermode=0, eva=3242745808) at /usr/src/sys/i386/i386/trap.c:841 #5 0xc0ae4b5c in trap (frame=0xe5726af8) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac926b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07d15b6 in free (addr=0xc57bc700, mtp=0xc0c6b380) at vm_page.h:266 #8 0xc09ec1a3 in workitem_free (item=0xc57bc700, type=Variable "type" is not available. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:641 #9 0xc09ec329 in handle_allocindir_partdone (aip=0xc57bc700) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4487 #10 0xc09f2d5f in softdep_disk_write_complete (bp=0xc52cfbb0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4312 #11 0xc084f006 in bufdone_finish (bp=0xc52cfbb0) at buf.h:443 #12 0xc084f47d in bufdone (bp=0xc52cfbb0) at /usr/src/sys/kern/vfs_bio.c:3177 #13 0xc078bfa8 in g_vfs_done (bip=0xc628a840) at /usr/src/sys/geom/geom_vfs.c:97 #14 0xc084957d in biodone (bp=0xc628a840) at /usr/src/sys/kern/vfs_bio.c:3013 #15 0xc078815f in g_io_schedule_up (tp=0xc54e1000) at /usr/src/sys/geom/geom_io.c:587 #16 0xc07884ae in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #17 0xc07bd0a9 in fork_exit (callout=0xc0788440 , arg=0x0, frame=0xe5726d38) at /usr/src/sys/kern/kern_fork.c:810 #18 0xc0ac92e0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAksCC40ACgkQi+vbBBjt66Bs/QCfTf5UNkbSRo3PEEPcnC0GDIRl kcoAn1goCLS8RlfL97pu7lyjjzVF4vQM =jxSt -----END PGP SIGNATURE----- From freebsd at abv.bg Tue Nov 17 05:54:20 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Tue Nov 17 05:54:33 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem Message-ID: <456530742.21066.1258437272093.JavaMail.apache@mail51.abv.bg> indeed you get bonus points if you firewall yourself :) and of course this is not the first time I do that so my score is pretty good however my favourite is to forget about net.inet.ip.forwarding when I upgrade routers with many clients :) Tim, thanks for your hints...but I don't understand this one: >2nd, you buildworld and installworld into the diskless root, but never >use it. You're using disk space you can reclaim. how so I never use it and can reclaim diskspace ? thanks, mgp ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From rui.pfcosta at gmail.com Tue Nov 17 13:25:13 2009 From: rui.pfcosta at gmail.com (Rui Costa) Date: Tue Nov 17 13:25:20 2009 Subject: FreeBSD installation freeze! - FreeBSD doesn't like my hardware? Message-ID: When installing freebsd (7.2, 8.0 betas, rc1, rc2, rc3 - AMD64) on a Clevo M540SR laptop (chipset VIA VN896), after menu option selection, the boot process freezes at "Trying to mount root from ufs:/dev/md0". On verbose booting it freezes giving some mode information: md0: Preloaded image 4194304 bytes at 0xffffffff80c4be40 ATA PseudoRAID loaded flowtable cleaner started warning: no time-of-day clock registered, system time will not be set accurately Trying to mount root from ufs:/dev/md0 Start_init: trying /sbin/init Start_init: trying /sbin/oinit Start_init: trying /sbin/init.bak Start_init: trying /rescue/init Start_init: trying /stand/sysinstall I've tried already several boot hints (any of them with success) such as: apic.0.disabled = 1 sio.0.disasabled = 1 sio.1.disabled = 1 fdc.disabled = 1 kbdmux.0.disabled = 1 A possible solution I found over the internet would be to disable USB 2.0 support on bios, but bios options are very limited and won't allow me to do that. I can install FreeBSD 6.4 without any trouble and later upgrade to 7.0 went flawlessly, but upgrade to 7.2 brings up the freezes again on boot. From amarat at ksu.ru Tue Nov 17 13:33:13 2009 From: amarat at ksu.ru (Marat N.Afanasyev) Date: Tue Nov 17 13:33:21 2009 Subject: AMD SR5690/SP5100 chipset Message-ID: <4B02A3A6.8050301@ksu.ru> Hello! I wonder is there any support for AMD SR5690/SP5100 chipset in FreeBSD? -- SY, Marat From matt at madhaus.cns.utoronto.ca Tue Nov 17 15:15:00 2009 From: matt at madhaus.cns.utoronto.ca (Matt Wilks) Date: Tue Nov 17 15:15:09 2009 Subject: NSIS compile failed on FreeBSD 7.2 Message-ID: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> I'm attempting to install NSIS (http://nsis.sourceforge.net/) on an amd64 FreeBSD 7.2 system and having trouble. When I run scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all NSIS_CONFIG_CONST_DATA_PATH=no in the source directory for NSIS, I get a bunch of errors that look like: /usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter A google search gives me a link to this bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582 that doesn't seem to have been touched since 2006. Is there someway around this compile error? Thanks, Matt From dimitry at andric.com Tue Nov 17 15:30:57 2009 From: dimitry at andric.com (Dimitry Andric) Date: Tue Nov 17 15:31:05 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> Message-ID: <4B02C1B7.2030708@andric.com> On 2009-11-17 15:48, Matt Wilks wrote: > in the source directory for NSIS, I get a bunch of errors that look like: > > /usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t' > ('unsigned int') as first parameter Does a .cpp file consisting of just the following: #include compile on your system? If so, it is most likely something in the NSIS headers that screws up either the definition of operator new, size_t, or some other vital thing. From mikael at t-online.hu Tue Nov 17 16:18:04 2009 From: mikael at t-online.hu (Mikael Bak) Date: Tue Nov 17 16:18:29 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> Message-ID: <4B02CCBA.4070909@t-online.hu> Matt Wilks wrote: > I'm attempting to install NSIS (http://nsis.sourceforge.net/) on an > amd64 FreeBSD 7.2 system and having trouble. When I run > [snip] >From the project's home page: "NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers." Is this supposed to compile on unix-like systems? Mikael From freebsd at jdc.parodius.com Tue Nov 17 16:38:19 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Tue Nov 17 16:38:26 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <4B02CCBA.4070909@t-online.hu> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> <4B02CCBA.4070909@t-online.hu> Message-ID: <20091117163754.GA98592@icarus.home.lan> On Tue, Nov 17, 2009 at 05:18:02PM +0100, Mikael Bak wrote: > Matt Wilks wrote: > > I'm attempting to install NSIS (http://nsis.sourceforge.net/) on an > > amd64 FreeBSD 7.2 system and having trouble. When I run > > > [snip] > > >From the project's home page: > "NSIS (Nullsoft Scriptable Install System) is a professional open source > system to create Windows installers." > > Is this supposed to compile on unix-like systems? Yes it is. It's supposed to be compilable on any POSIX-compliant system, without requiring WINE. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From info at martenvijn.nl Tue Nov 17 20:02:52 2009 From: info at martenvijn.nl (Marten Vijn) Date: Tue Nov 17 20:03:00 2009 Subject: 8.0-rc2 dropped hardwaresupport In-Reply-To: <20091112180743.GA23798@gta.com> References: <20091112152154.91849.qmail@mailgate.gta.com> <1258046854.4826.160.camel@mvn-desktop> <20091112180743.GA23798@gta.com> Message-ID: <1258488174.5002.6.camel@mvn-desktop> On Thu, 2009-11-12 at 13:07 -0500, Larry Baird wrote: > Marten, > > > I did some more testing, and I made an error on the ALIX 1C since it > > does boot but it hangs on devd.... > > > but for WRAP 1C and 2E: > > > > PC Engines WRAP.2B/2C v1.11 > > 640 KB Base Memory > > 130048 KB Extended Memory > > > > 01F0 Master 044A CF CARD 2GB > > Phys C/H/S 3909/16/63 Log C/H/S 977/64/63 > > > > 1 FreeBSD > > 2 FreeBSD > > > > F6 PXE > > Boot: 1 ######## > > > > Here it ends.... > > > > Would you recommend to downgrade the bios? I have version 1.11 on all > > boards. > The 0.99h BIOS is for ALIX boards. I am running v1.11 on my WRAP boards. > PC Engines WRAP.1C/1D/1E v1.11 > 640 KB Base Memory > 130048 KB Extended Memory > > Looking at your geometry, I would recommend verifing that the BIOS is set > for LBA mode (not CHS). If you change mode, you will probably need to > reinstall FreeBSD. Thanks for your input, I seems NanoBSD specific, while I have been trying different disk geometrics and multiple cf-cards on NanoBSD I was not succesfull yet. With TinyBSD and mfsBSD I am able to create bootable images, for WRAP 1C and 2E. If I find a solution for NanoBSD, I 'll post it, thanks, Marten -- http://www.voedselbankleiden.nl needs your help! http://martenvijn.nl http://bsd.wifisoft.org/nek/ http://opencommunitycamp.org OCC 2010 From info at martenvijn.nl Tue Nov 17 21:13:24 2009 From: info at martenvijn.nl (Marten Vijn) Date: Tue Nov 17 21:13:32 2009 Subject: 8.0-rc2 meshmode breaks hostap mode on ath0 In-Reply-To: <1258035995.4826.0.camel@mvn-desktop> References: <1258035995.4826.0.camel@mvn-desktop> Message-ID: <1258492407.5002.9.camel@mvn-desktop> On Thu, 2009-11-12 at 15:26 +0100, Marten Vijn wrote: > hi > > 8.0-rc2 802.11s breaks ap mode: > - on the same interface > - when mesh is on diffent channel > > how-to reproduce: > ifconfig wlan0 create wlandev ath0 wlanmode hostap > ifconfig wlan0 ssid bert channel 3 up > ifconfig wlan1 create wlandev ath0 wlanmode mesh > ifconfig wlan1 channel 3 meshid ernie up > ifconfig ==> wlan0 => status: running > ifconfig wlan1 channel 7 > ifconfig ==> wlan0 => status: no carrier and is persistent in: 8.0-PRERELEASE tinybsd# uname -a FreeBSD tinybsd.freebsd.org 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0 r199257: Tue Nov 17 21:26:00 CET 2009 root@master:/usr/obj/usr/src/sys/TINYBSD i386 tinybsd# > > details below, > > kind regards, > Marten dmesg: tinybsd# uname -a FreeBSD tinybsd.freebsd.org 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0 r199257: Tue Nov 17 21:26:00 CET 2009 root@master:/usr/obj/usr/src/sys/TINYBSD i386 tinybsd# dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-PRERELEASE #0 r199257: Tue Nov 17 21:26:00 CET 2009 root@master:/usr/obj/usr/src/sys/TINYBSD i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by National Semi (233.33-MHz 586-class CPU) Origin = "Geode by NSC" Id = 0x540 Stepping = 0 Features=0x808131 real memory = 134217728 (128 MB) avail memory = 120905728 (115 MB) wlan: mac acl policy registered kbd0 at kbdmux0 ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. pcib0: pcibus 0 on motherboard pci0: on pcib0 ath0: mem 0x80000000-0x8000ffff irq 12 at device 13.0 on pci0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 sis0: port 0x1000-0x10ff mem 0x80040000-0x80040fff irq 10 at device 14.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:0d:b9:05:41:b4 sis0: [ITHREAD] isab0: port 0xf400-0xf43f,0xf600-0xf63f at device 18.0 on pci0 isa0: on isab0 pci0: at device 18.1 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 18.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 18.3 (no driver attached) pci0: at device 18.5 (no driver attached) ohci0: mem 0xf0000000-0xf0000fff irq 9 at device 19.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 cpu0 on motherboard pmtimer0 on isa0 orm0: at iomem 0xe0000-0xe7fff pnpid ORM0000 on isa0 atrtc0: at port 0x70 irq 8 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) RTC BIOS diagnostic error 80 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 ad0ugen0.1: <(0x0e11)> at usbus0 uhub0: <(0x0e11) OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 : FAILURE - SETFEATURES SET TRANSFER MODE status=51 error=4 ad0: 61MB at ata0-master BIOSPIO GEOM: ad0: geometry does not match labuhub0: 3 ports with 3 removable, self powered el (4h,32s != 8h,32s). GEOM: ad0: media size does not match label. Trying to mount root from ufs:/dev/ad0a wlan0: Ethernet address: 00:0b:6b:34:58:99 wlan1: Ethernet address: 00:0b:6b:34:58:99 sis0: link state changed to DOWN tinybsd# > > dmesg: > > # dmesg > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-RC2 #0: Tue Nov 10 20:24:18 CET 2009 > root@master:/usr/obj/nanobsd.full/usr/src/sys/KERNEL i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) > Origin = "AuthenticAMD" Id = 0x494 Stepping = 4 > Features=0x1 > real memory = 67108864 (64 MB) > avail memory = 55230464 (52 MB) > wlan: mac acl policy registered > kbd1 at kbdmux0 > ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 > ACPI: Table initialisation failed: AE_NOT_FOUND > ACPI: Try disabling either ACPI or apic support. > *** WARNING: missing CPU_ELAN -- timekeeping may be wrong > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > ath0: mem 0xa0000000-0xa000ffff irq 10 at device 16.0 on > pci0 > ath0: [ITHREAD] > ath0: AR5212 mac 5.9 RF5112 phy 4.3 > sis0: port 0xe000-0xe0ff mem > 0xa0010000-0xa0010fff irq 11 at device 18.0 on pci0 > sis0: Silicon Revision: DP83816A > miibus0: on sis0 > nsphyter0: PHY 0 on miibus0 > nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sis0: Ethernet address: 00:00:24:c5:59:8c > sis0: [ITHREAD] > sis1: port 0xe100-0xe1ff mem > 0xa0011000-0xa0011fff irq 5 at device 19.0 on pci0 > sis1: Silicon Revision: DP83816A > miibus1: on sis1 > nsphyter1: PHY 0 on miibus1 > nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sis1: Ethernet address: 00:00:24:c5:59:8d > sis1: [ITHREAD] > sis2: port 0xe200-0xe2ff mem > 0xa0012000-0xa0012fff irq 9 at device 20.0 on pci0 > sis2: Silicon Revision: DP83816A > miibus2: on sis2 > nsphyter2: PHY 0 on miibus2 > nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sis2: Ethernet address: 00:00:24:c5:59:8e > sis2: [ITHREAD] > cpu0 on motherboard > isa0: on motherboard > pmtimer0 on isa0 > orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to get the current command byte value. > atrtc0: at port 0x70 irq 8 on isa0 > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on > isa0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > uart1: [FILTER] > Timecounters tick every 1.000 msec > ad0: 1923MB at ata0-master PIO4 > Trying to mount root from ufs:/dev/ad0s1a > Invalid time in real time clock. > Check and reset the date immediately! > wlan0: Ethernet address: 00:0b:6b:34:58:99 > wlan1: Ethernet address: 00:0b:6b:34:58:99 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...0 0 done > All buffers synced. > Uptime: 9m38s > Rebooting... > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-RC2 #0: Tue Nov 10 20:24:18 CET 2009 > root@master:/usr/obj/nanobsd.full/usr/src/sys/KERNEL i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Am5x86 Write-Back (486-class CPU) > Origin = "AuthenticAMD" Id = 0x4f4 Stepping = 4 > Features=0x1 > real memory = 67108864 (64 MB) > avail memory = 55230464 (52 MB) > wlan: mac acl policy registered > kbd1 at kbdmux0 > ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 > ACPI: Table initialisation failed: AE_NOT_FOUND > ACPI: Try disabling either ACPI or apic support. > *** WARNING: missing CPU_ELAN -- timekeeping may be wrong > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > ath0: mem 0xa0000000-0xa000ffff irq 10 at device 16.0 on > pci0 > ath0: [ITHREAD] > ath0: AR5212 mac 5.9 RF5112 phy 4.3 > sis0: port 0xe000-0xe0ff mem > 0xa0010000-0xa0010fff irq 11 at device 18.0 on pci0 > sis0: Silicon Revision: DP83816A > miibus0: on sis0 > nsphyter0: PHY 0 on miibus0 > nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sis0: Ethernet address: 00:00:24:c5:59:8c > sis0: [ITHREAD] > sis1: port 0xe100-0xe1ff mem > 0xa0011000-0xa0011fff irq 5 at device 19.0 on pci0 > sis1: Silicon Revision: DP83816A > miibus1: on sis1 > nsphyter1: PHY 0 on miibus1 > nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sis1: Ethernet address: 00:00:24:c5:59:8d > sis1: [ITHREAD] > sis2: port 0xe200-0xe2ff mem > 0xa0012000-0xa0012fff irq 9 at device 20.0 on pci0 > sis2: Silicon Revision: DP83816A > miibus2: on sis2 > nsphyter2: PHY 0 on miibus2 > nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sis2: Ethernet address: 00:00:24:c5:59:8e > sis2: [ITHREAD] > cpu0 on motherboard > isa0: on motherboard > pmtimer0 on isa0 > orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to get the current command byte value. > atrtc0: at port 0x70 irq 8 on isa0 > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on > isa0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > uart1: [FILTER] > Timecounters tick every 1.000 msec > ad0: 1923MB at ata0-master PIO4 > Trying to mount root from ufs:/dev/ad0s1a > Invalid time in real time clock. > Check and reset the date immediately! > > > > # tail -n 40 /var/log/messages > Nov 10 19:31:30 kernel: nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, auto > Nov 10 19:31:30 kernel: sis1: Ethernet address: 00:00:24:c5:59:8d > Nov 10 19:31:30 kernel: sis1: [ITHREAD] > Nov 10 19:31:30 kernel: sis2: port > 0xe200-0xe2ff mem 0xa0012000-0xa0012fff irq 9 at device 20.0 on pci0 > Nov 10 19:31:30 kernel: sis2: Silicon Revision: DP83816A > Nov 10 19:31:30 kernel: miibus2: on sis2 > Nov 10 19:31:30 kernel: nsphyter2: PHY > 0 on miibus2 > Nov 10 19:31:30 kernel: nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, auto > Nov 10 19:31:30 kernel: sis2: Ethernet address: 00:00:24:c5:59:8e > Nov 10 19:31:30 kernel: sis2: [ITHREAD] > Nov 10 19:31:30 kernel: cpu0 on motherboard > Nov 10 19:31:30 kernel: isa0: on motherboard > Nov 10 19:31:30 kernel: pmtimer0 on isa0 > Nov 10 19:31:30 kernel: orm0: at iomem 0xc8000-0xd0fff > pnpid ORM0000 on isa0 > Nov 10 19:31:30 kernel: ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > Nov 10 19:31:30 kernel: ata0: [ITHREAD] > Nov 10 19:31:30 kernel: ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > Nov 10 19:31:30 kernel: ata1: [ITHREAD] > Nov 10 19:31:30 kernel: atkbdc0: at port > 0x60,0x64 on isa0 > Nov 10 19:31:30 kernel: atkbd0: irq 1 on atkbdc0 > Nov 10 19:31:30 kernel: kbd0 at atkbd0 > Nov 10 19:31:30 kernel: atkbd0: [GIANT-LOCKED] > Nov 10 19:31:30 kernel: atkbd0: [ITHREAD] > Nov 10 19:31:30 kernel: psm0: unable to get the current command byte > value. > Nov 10 19:31:30 kernel: atrtc0: at port 0x70 irq 8 > on isa0 > Nov 10 19:31:30 kernel: uart0: <16550 or compatible> at port > 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > Nov 10 19:31:30 kernel: uart0: [FILTER] > Nov 10 19:31:30 kernel: uart0: console (9600,n,8,1) > Nov 10 19:31:30 kernel: uart1: <16550 or compatible> at port > 0x2f8-0x2ff irq 3 on isa0 > Nov 10 19:31:30 kernel: uart1: [FILTER] > Nov 10 19:31:30 kernel: Timecounters tick every 1.000 msec > Nov 10 19:31:30 kernel: ad0: 1923MB at > ata0-master PIO4 > Nov 10 19:31:30 kernel: Trying to mount root from ufs:/dev/ad0s1a > Nov 10 19:31:30 kernel: Invalid time in real time clock. > Nov 10 19:31:30 kernel: Check and reset the date immediately! > Nov 10 19:31:54 login: ROOT LOGIN (root) ON ttyu0 > Nov 10 19:32:05 kernel: wlan0: Ethernet address: 00:0b:6b:34:58: > Nov 10 19:32:05 kernel: 99 > Nov 10 19:32:26 kernel: wlan1: Ethernet add > Nov 10 19:32:26 kernel: ress: 00:0b:6b:34:58:99 > > > -- http://www.voedselbankleiden.nl needs your help! http://martenvijn.nl http://bsd.wifisoft.org/nek/ http://opencommunitycamp.org OCC 2010 From tinderbox at freebsd.org Tue Nov 17 22:46:16 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 17 22:46:33 2009 Subject: [releng_8 tinderbox] failure on amd64/amd64 Message-ID: <200911172246.nAHMkFfM017969@freebsd-current.sentex.ca> TB --- 2009-11-17 21:15:27 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-17 21:15:27 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2009-11-17 21:15:27 - cleaning the object tree TB --- 2009-11-17 21:15:48 - cvsupping the source tree TB --- 2009-11-17 21:15:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2009-11-17 21:16:17 - building world TB --- 2009-11-17 21:16:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-17 21:16:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-17 21:16:17 - TARGET=amd64 TB --- 2009-11-17 21:16:17 - TARGET_ARCH=amd64 TB --- 2009-11-17 21:16:17 - TZ=UTC TB --- 2009-11-17 21:16:17 - __MAKE_CONF=/dev/null TB --- 2009-11-17 21:16:17 - cd /src TB --- 2009-11-17 21:16:17 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 17 21:16:18 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Nov 17 22:43:03 UTC 2009 TB --- 2009-11-17 22:43:03 - generating LINT kernel config TB --- 2009-11-17 22:43:03 - cd /src/sys/amd64/conf TB --- 2009-11-17 22:43:03 - /usr/bin/make -B LINT TB --- 2009-11-17 22:43:03 - building LINT kernel TB --- 2009-11-17 22:43:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-17 22:43:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-17 22:43:03 - TARGET=amd64 TB --- 2009-11-17 22:43:03 - TARGET_ARCH=amd64 TB --- 2009-11-17 22:43:03 - TZ=UTC TB --- 2009-11-17 22:43:03 - __MAKE_CONF=/dev/null TB --- 2009-11-17 22:43:03 - cd /src TB --- 2009-11-17 22:43:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 17 22:43:03 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/cam/ata/ata_xpt.c: In function 'ata_scan_lun': /src/sys/cam/ata/ata_xpt.c:1042: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) /src/sys/cam/ata/ata_xpt.c: In function 'ata_device_transport': /src/sys/cam/ata/ata_xpt.c:1179: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) /src/sys/cam/ata/ata_xpt.c: In function 'scsi_set_transfer_settings': /src/sys/cam/ata/ata_xpt.c:1327: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) /src/sys/cam/ata/ata_xpt.c: In function 'scsi_toggle_tags': /src/sys/cam/ata/ata_xpt.c:1441: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-17 22:46:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-17 22:46:14 - ERROR: failed to build lint kernel TB --- 2009-11-17 22:46:14 - 3928.28 user 881.40 system 5447.07 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From tinderbox at freebsd.org Tue Nov 17 23:16:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Nov 17 23:16:59 2009 Subject: [releng_8 tinderbox] failure on i386/i386 Message-ID: <200911172316.nAHNGkGH082074@freebsd-current.sentex.ca> TB --- 2009-11-17 22:13:36 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-17 22:13:36 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2009-11-17 22:13:36 - cleaning the object tree TB --- 2009-11-17 22:14:01 - cvsupping the source tree TB --- 2009-11-17 22:14:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2009-11-17 22:14:24 - building world TB --- 2009-11-17 22:14:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-17 22:14:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-17 22:14:24 - TARGET=i386 TB --- 2009-11-17 22:14:24 - TARGET_ARCH=i386 TB --- 2009-11-17 22:14:24 - TZ=UTC TB --- 2009-11-17 22:14:24 - __MAKE_CONF=/dev/null TB --- 2009-11-17 22:14:24 - cd /src TB --- 2009-11-17 22:14:24 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 17 22:14:24 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Nov 17 23:13:12 UTC 2009 TB --- 2009-11-17 23:13:12 - generating LINT kernel config TB --- 2009-11-17 23:13:12 - cd /src/sys/i386/conf TB --- 2009-11-17 23:13:12 - /usr/bin/make -B LINT TB --- 2009-11-17 23:13:12 - building LINT kernel TB --- 2009-11-17 23:13:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-17 23:13:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-17 23:13:12 - TARGET=i386 TB --- 2009-11-17 23:13:12 - TARGET_ARCH=i386 TB --- 2009-11-17 23:13:12 - TZ=UTC TB --- 2009-11-17 23:13:12 - __MAKE_CONF=/dev/null TB --- 2009-11-17 23:13:12 - cd /src TB --- 2009-11-17 23:13:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Nov 17 23:13:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/cam/ata/ata_xpt.c: In function 'ata_scan_lun': /src/sys/cam/ata/ata_xpt.c:1042: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) /src/sys/cam/ata/ata_xpt.c: In function 'ata_device_transport': /src/sys/cam/ata/ata_xpt.c:1179: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) /src/sys/cam/ata/ata_xpt.c: In function 'scsi_set_transfer_settings': /src/sys/cam/ata/ata_xpt.c:1327: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) /src/sys/cam/ata/ata_xpt.c: In function 'scsi_toggle_tags': /src/sys/cam/ata/ata_xpt.c:1441: error: 'CAM_PRIORITY_NORMAL' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-17 23:16:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-17 23:16:46 - ERROR: failed to build lint kernel TB --- 2009-11-17 23:16:46 - 2767.16 user 624.06 system 3789.39 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From mav at FreeBSD.org Tue Nov 17 23:30:55 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Nov 17 23:31:02 2009 Subject: HEADS UP: major CAM ATA MFC Message-ID: <4B03322A.2080608@FreeBSD.org> Hi. I want to notice, that I've just merged from HEAD to 8-STABLE latest results of my last months work on CAM-based ATA implementation and CAM subsystem itself. Please contact me if you will have any problems, questions, propositions, ... What's done: - major code cleanup. Many SCSIsms in ATA code removed, or reworked for ATA specifics. Many ATA support parts reworked or newly implemented; - CAM code took some fixes and optimizations. Luckily no major changes were required yet. - NCQ support re-factored. Same as for SCSI, non-capable devices now limited by queue depth of 2, to let request sorter do it's job better. - Port Multipliers support re-factored. Is is more stable now. Devices hot-insert/remove supported. Implemented reinitialization after bus resets. - ahci(4) and siis(4) drivers took many changes, including improved timeout handling, error recovery and performance optimizations. - added basic support for PATA transport. After ata(4) drivers wrapper will be finished, it will allow to completely disable old ATA infrastructure. - camcontrol tool now reports more information about ATA devices and supports ATA Power Management. - added support for ATA devices with large sector size, declared by ATA-7 spec (only theoretically now, I haven't seen such yet) - added quirks mechanism for ATA, to allow, for example, to disable NCQ, or later DMA, for specific device model or firmware revision, - added support for DMA-incapable, and some old ATA devices; - implemented ATA error reporting. Things to be done yet: - timeouts and hard errors recovery process with Port Multipliers used can cause deadlocks if happen under heavy load. Any way it is a step forward, as previously it just was not recovering at all. - devices connected using Port Multipliers detected asynchronously, and in some cases they may not get in time for root mounting. - interface mode control possible only using loader tunables, but not with camcontrol. - NCQ is not used for devices with less tags supported then controller capable (it is quite rare). Many thanks to iXsystems Inc for supporting my work, making this all possible. Also thanks to Vitsch Electronics, Sentex Corp, lissyara.su, and many other people for hardware donations. Feedbacks are welcome as always. -- Alexander Motin From fjwcash at gmail.com Wed Nov 18 00:29:07 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Nov 18 00:29:14 2009 Subject: Support for SAS/SATA non-RAID adapters Message-ID: I've spent the better part of today doing various web searches in Google, searches in newegg.ca/ncix.com, digging through mailing list archives (-hardware and -stable), man pages, and vendor websites looking for well-supported SATA/SAS adapters for use in FreeBSD storage servers. These servers will be using ZFS, so will not need fancy RAID controllers (currently, we're using 3Ware 9550SXU and 9650SE RAID controllers, which are increasingly hard to buy and very expensive at $1200+ CDN). The chassis have hot-plug SATA backplanes, so can use multi-lane cabling or standard SATA cabling. So far, I've come across a nice selection of LSI and Promise controllers, that are in the $200 - $400 CDN range, and seem to fit the bill. However, I can't find anything that definitively states whether they are supported by FreeBSD 7.x or 8.x. Thus, my questions to all of you: Are any of the following supported by FreeBSD 7/8? If so, by what driver? And do you have any experience (good/bad/otherwise) with any of them? LSI SAS 9211-8i 8-port SAS/SATA PCIe LSI SAS 3081E-R 8-port SAS/SATA PCIe LSI SAS 3080X-R 8-port SATA/SATA PCI-X Promise SuperTrak EX12350 12-port SATA PCIe Promise SuperTrak EX16350 16-port SATA PCIe Promise SuperTrak EX16300 16-port SATA PCI-X Promise SuperTrak EX16650 16-port SAS/SATA PCIe Any recommendations on other SAS/SATA controllers to look at (just not anything with MegaRAID in the name)? -- Freddie Cash fjwcash@gmail.com From ari at ish.com.au Wed Nov 18 01:09:45 2009 From: ari at ish.com.au (Aristedes Maniatis) Date: Wed Nov 18 01:09:52 2009 Subject: vnode_pager_putpages error Message-ID: <4B034953.8030404@ish.com.au> FreeBSD 7.2 amd64. Running Apache httpd application (MPM worker threads) and other applications. ZFS file system. After some weeks of uptime, we are seeing these errors repeated many times: vnode_pager_putpages: I/O error 69 vnode_pager_putpages: residual I/O 16384 at 0 After that, httpd dies. On another occasion the entire system rebooted and we are guessing the symptoms are the same, but the console was lost so we can't tell for sure. * Can sometime tell me where I found out what error 69 means? Is there something in the docs somewhere I can look at? * My uninformed guess is that this is some sort of swap/memory exhaustion. Could it be a memory leak in httpd (or one of its modules)? Or could ZFS memory exhaustion be the issue here? If so, we'd probably move to 8.0 as soon as possible with all its ZFS improvements. Any clues to tracking this down would be appreciated. It is a production server and doesn't happen often enough to easily reproduce. Thanks Ari Maniatis -- --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From fbsdlist at src.cx Wed Nov 18 02:13:02 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Wed Nov 18 02:13:08 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: > ?LSI SAS 3080X-R ? ?8-port SATA/SATA PCI-X This one uses LSI1068 chip which is supported by mpt driver. I'm using motherboard with an on-board equivalent of this and don't have much to complain about. I did see some CRC errors with SATA drives in 3Gbps mode, but those went away after updating firmware to 1.29.0.0. I've seen some comments on zfs-discuss mailing list that -IR variant of the firmware (the one that provides RAID0/1 capabilities) does have some stability issues and recommended going with simpler -IT version (just pass-through disks). --Artem From fbsdlist at src.cx Wed Nov 18 02:25:39 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Wed Nov 18 02:25:46 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: In general, I've found following page very informative about what's available: http://www.hardforums.com/showthread.php?t=1413050 I've also tried AOC-SAT2-MV8: http://www.supermicro.com/products/accessories/addon/AOC-SAT2-MV8.cfm It's based on Marvell 88sx8061 chipset. Technically it is supported by FreeBSD, but I'd rather stay away from it at least for now. The main issue is that the largest transfer size is 32K. ZFS does push this card hard and under load this card showed noticeably slower transfer rate than LSI1068 under the same circumstances. Folks on zfs-discuss list also mentioned issues with hot-swap on this card on controller level. The somewhat better news is that NetBSD does seem to have much better driver for this marvell chip. If someone gets to port it to FreeBSD, the card may be pretty decent choice for those who have PCI-X slot on-board. --Artem On Tue, Nov 17, 2009 at 6:12 PM, Artem Belevich wrote: >> ?LSI SAS 3080X-R ? ?8-port SATA/SATA PCI-X > > This one uses LSI1068 chip which is supported by mpt driver. I'm using > motherboard with an on-board equivalent of this and don't have much to > complain about. I did see some CRC errors with SATA drives in 3Gbps > mode, but those went away after updating firmware to 1.29.0.0. I've > seen some comments on zfs-discuss mailing list that -IR variant of the > firmware (the one that provides RAID0/1 capabilities) does have some > stability issues and recommended going with simpler -IT version (just > pass-through disks). > > --Artem > From fjwcash at gmail.com Wed Nov 18 04:38:22 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Nov 18 04:38:34 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: On Tue, Nov 17, 2009 at 6:12 PM, Artem Belevich wrote: >> ?LSI SAS 3080X-R ? ?8-port SATA/SATA PCI-X > > This one uses LSI1068 chip which is supported by mpt driver. I'm using > motherboard with an on-board equivalent of this and don't have much to > complain about. I did see some CRC errors with SATA drives in 3Gbps > mode, but those went away after updating firmware to 1.29.0.0. I've > seen some comments on zfs-discuss mailing list that -IR variant of the > firmware (the one that provides RAID0/1 capabilities) does have some > stability issues and recommended going with simpler -IT version (just > pass-through disks). If that one uses the LSI1068 chipset, do you know which one uses the LSI1078 chipset? I've seen that number in the comments in one of the mf* drivers (think it was mfi). How does one determine which actual chipset is in which controller? Do they have that buried in the docs somewhere? I've also found a couple of Areca cards (PCI-X, non-RAID/PCIe RAID), and have heard good things about Areca support in FreeBSD. Any comments on their quality/performance/reliability? -- Freddie Cash fjwcash@gmail.com From fbsdlist at src.cx Wed Nov 18 05:59:03 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Wed Nov 18 05:59:10 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: Hi, > If that one uses the LSI1068 chipset, do you know which one uses the > LSI1078 chipset? Supermicro's AOC-USAS-H8iR uses LSI1078: http://www.supermicro.com/products/accessories/addon/AOC-USAS-H8iR.cfm Dell PERC 6/i is based on LSI1078 as well. http://www.dell.com/content/topics/topic.aspx/global/products/pvaul/topics/en/us/raid_controller?c=us&l=en&cs=555 However, these cards are full-blown RAID controllers with their own CPU, memory and corresponding price. > ?I've seen that number in the comments in one of the mf* drivers (think it was mfi). Yes, it is indeed mfi that supports LSI1078. > How does one determine which actual chipset is in which controller? ?Do they have that buried in the docs somewhere? The docs, if you're lucky. Cards listed above mention controller chip explicitly on the product pages. --Artem From egrosbein at rdtc.ru Wed Nov 18 06:04:40 2009 From: egrosbein at rdtc.ru (Eugene Grosbein) Date: Wed Nov 18 06:04:49 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B03322A.2080608@FreeBSD.org> References: <4B03322A.2080608@FreeBSD.org> Message-ID: <4B038E75.1010501@rdtc.ru> Alexander Motin wrote: > Feedbacks are welcome as always. Today's RELENG_8 build is broken (my /usr/src is symlink to /usr/local/src): # make -j3 MODULES_WITH_WORLD=yes buildworld [skip] ===> sys/modules/ahci (all) cc -O2 -pipe -march=prescott -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-gr owth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wred undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c / usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_timeout ': /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1286: error: 'struct ahci_ channel' has no member named 'fatalerr' /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_end_tra nsaction': /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1368: error: 'struct ahci_ channel' has no member named 'fatalerr' /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1384: error: 'struct ahci_ channel' has no member named 'fatalerr' /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1396: error: 'struct ahci_ channel' has no member named 'fatalerr' /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1405: error: 'struct ahci_ channel' has no member named 'fatalerr' /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1447: error: 'struct ahci_ channel' has no member named 'fatalerr' /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_reset': /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1703: error: 'struct ahci_ channel' has no member named 'fatalerr' *** Error code 1 Stop in /usr/local/src/sys/modules/ahci. *** Error code 1 Stop in /usr/local/src/sys/modules. *** Error code 1 Stop in /usr/local/src/sys. *** Error code 1 Stop in /usr/local/src. *** Error code 1 Stop in /usr/local/src. *** Error code 1 Stop in /usr/local/src. From freebsd at jdc.parodius.com Wed Nov 18 06:17:28 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Wed Nov 18 06:17:36 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B038E75.1010501@rdtc.ru> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> Message-ID: <20091118061726.GA1675@icarus.home.lan> I didn't have this problem. System has AHCI in use, and the kernel is built to make use of modular atacore. Specifically: # Modular ATA device atacore # Core ATA functionality device ataisa # ISA bus support device atapci # PCI bus support; only generic chipset support device ataahci # AHCI SATA device ataintel # Intel Confirmation: FreeBSD icarus.home.lan 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Tue Nov 17 20:07:21 PST 2009 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 world/kernel built with make -j2 buildworld / make -j2 buildkernel. csup last run against cvsup10.freebsd.org approximately 2 hours ago. I did notice a number of commits to ATA, XPT, CAM, etc. ~8-10 hours ago as well, but even more ~2 hours ago. I assume the delays are due to what the cvsup master vs. mirrors have and how often they sync. I'd recommend you re-csup with a different mirror and see if there are any changes. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | On Wed, Nov 18, 2009 at 01:04:37PM +0700, Eugene Grosbein wrote: > Alexander Motin wrote: > > > Feedbacks are welcome as always. > > Today's RELENG_8 build is broken (my /usr/src is symlink to /usr/local/src): > > # make -j3 MODULES_WITH_WORLD=yes buildworld > [skip] > ===> sys/modules/ahci (all) > cc -O2 -pipe -march=prescott -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-gr > owth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wred > undant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c / > usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_timeout > ': > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1286: error: 'struct ahci_ > channel' has no member named 'fatalerr' > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_end_tra > nsaction': > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1368: error: 'struct ahci_ > channel' has no member named 'fatalerr' > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1384: error: 'struct ahci_ > channel' has no member named 'fatalerr' > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1396: error: 'struct ahci_ > channel' has no member named 'fatalerr' > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1405: error: 'struct ahci_ > channel' has no member named 'fatalerr' > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1447: error: 'struct ahci_ > channel' has no member named 'fatalerr' > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_reset': > /usr/local/src/sys/modules/ahci/../../dev/ahci/ahci.c:1703: error: 'struct ahci_ > channel' has no member named 'fatalerr' > *** Error code 1 > > Stop in /usr/local/src/sys/modules/ahci. > *** Error code 1 > > Stop in /usr/local/src/sys/modules. > *** Error code 1 > > Stop in /usr/local/src/sys. > *** Error code 1 > > Stop in /usr/local/src. > *** Error code 1 > > Stop in /usr/local/src. > *** Error code 1 > > Stop in /usr/local/src. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From egrosbein at rdtc.ru Wed Nov 18 06:53:26 2009 From: egrosbein at rdtc.ru (Eugene Grosbein) Date: Wed Nov 18 06:53:33 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <20091118061726.GA1675@icarus.home.lan> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> Message-ID: <4B0399E3.6020609@rdtc.ru> Jeremy Chadwick wrote: > I didn't have this problem. System has AHCI in use, and the kernel is > built to make use of modular atacore. Specifically: [skip] > I'd recommend you re-csup with a different mirror and see if there are > any changes. I'll try. By the way, have you used MODULES_WITH_WORLD while building world? RELENG_8 still has a couple of other problems with this knob, needed patches are: -- sys/modules/dtrace/lockstat/Makefile.orig 2009-09-16 23:05:25.000000000 +0800 +++ sys/modules/dtrace/lockstat/Makefile 2009-09-16 23:05:45.000000000 +0800 @@ -5,7 +5,7 @@ KMOD= lockstat SRCS= lockstat.c -SRCS+= vnode_if.h +SRCS+= vnode_if.h opt_kdtrace.h CFLAGS+= -I${.CURDIR}/../../../cddl/compat/opensolaris \ -I${.CURDIR}/../../../cddl/contrib/opensolaris/uts/common \ --- sys/modules/sysvipc/sysvmsg/Makefile.orig 2009-09-16 23:04:00.000000000 +0800 +++ sys/modules/sysvipc/sysvmsg/Makefile 2009-09-16 23:04:12.000000000 +0800 @@ -3,6 +3,6 @@ .PATH: ${.CURDIR}/../../../kern KMOD= sysvmsg -SRCS= sysv_msg.c opt_sysvipc.h +SRCS= sysv_msg.c opt_sysvipc.h opt_compat.h .include --- sys/modules/sysvipc/sysvsem/Makefile.orig 2009-09-16 23:02:02.000000000 +0800 +++ sys/modules/sysvipc/sysvsem/Makefile 2009-09-16 23:01:51.000000000 +0800 @@ -3,6 +3,6 @@ .PATH: ${.CURDIR}/../../../kern KMOD= sysvsem -SRCS= sysv_sem.c opt_sysvipc.h +SRCS= sysv_sem.c opt_sysvipc.h opt_compat.h .include From randy at psg.com Wed Nov 18 07:19:47 2009 From: randy at psg.com (Randy Bush) Date: Wed Nov 18 07:19:54 2009 Subject: boot issues Message-ID: [ this happened a month ago and i backed off ] i386, 7.2-stable from last summer cvsupped releng_7 made and installed kernel buildworld boot -s installworld mergemaster reboot hung after beastie, just as it did the other month booted -s mount -2 / /etc/rc.d/hostid start /etc/rc.d/zfs start looked around and all seemed ok ^D came up ok and that is how it is running now but why will it boot through -s and not from beastie? randy From rink at FreeBSD.org Wed Nov 18 07:43:30 2009 From: rink at FreeBSD.org (Rink Springer) Date: Wed Nov 18 07:43:38 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: <20091118074329.GA13345@rink.nu> On Tue, Nov 17, 2009 at 08:38:21PM -0800, Freddie Cash wrote: > I've also found a couple of Areca cards (PCI-X, non-RAID/PCIe RAID), > and have heard good things about Areca support in FreeBSD. Any > comments on their quality/performance/reliability? I have got an Areca ARC-1110 4x SATA2 PCI-X card in my server, and I'm quite impressed with the performance; these cards do very well in terms I/O operations per second and the driver has been rock solid for me. The only downside is that they are quite expensive (but well worth it, IMO) Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From mav at FreeBSD.org Wed Nov 18 07:45:28 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Nov 18 07:45:35 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B038E75.1010501@rdtc.ru> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> Message-ID: <4B03A613.8060708@FreeBSD.org> Eugene Grosbein wrote: > Alexander Motin wrote: > >> Feedbacks are welcome as always. > > Today's RELENG_8 build is broken (my /usr/src is symlink to /usr/local/src): Can you try to update your sources again? ahci driver in 8-STABLE and HEAD are identical now and building fine in both, I've checked it yesterday. -- Alexander Motin From gjin at ubicom.com Wed Nov 18 07:46:29 2009 From: gjin at ubicom.com (Guojun Jin) Date: Wed Nov 18 07:46:36 2009 Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive References: Message-ID: Did newfs on those partition and made things worsen -- restore completely fails: (I had experienced another similar problem on an IDE, which works well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD 6.4. Is something new in 8.0 making disk partition schema changed? g_vfs_done():da0s3d[READ(offset=98304, length=16384)]error = 6 g_vfs_done():da0s3d[WRITE(offset=192806912, length=16384)]error = 6 fopen: Device not configured cannot create save file ./restoresymtable for symbol table abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scs i status == 0x0 (da0:umass-sim0:0:0:0): removing device entry ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) Device da0s3d went missing before all of the data could be written to it; expect data loss. 99 23:19 sysinstall 100 23:20 newfs /dev/da0s3d 101 23:20 newfs /dev/da0s3e 102 23:21 mount /dev/da0s3d /mnt 103 23:21 cd /mnt 104 23:21 dump -0f - /home | restore -rf - 105 23:27 history 15 -----Original Message----- From: Guojun Jin Sent: Tue 11/17/2009 11:05 PM To: freebsd-stable@freebsd.org Cc: questions@freebsd.org; freebsd-usb@freebsd.org Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive When mounting two partitions from a USB dirve, it can cause the drive access lock up for a long time. Details: Terminal 1 -- term1# mount /dev/da0s3d /mnt term1# cd /mnt ; rm -fr * when rm starts, go to terminal 2 and do: term2# mount /dev/da0s3e /dist ### this will hanging for a long time and USB hard drive activity light is off. After more than 1-2 minutes, mount returns, and the drive activity light is blinking, thus removing is going on. term2# ls /dist ### this will cause dUSB dirve hanging again -- no avtivity. Similarly, ls will finish in a couple of miniutes or longer, the rm command continues; but for a while, the drive activity will stop again. Reboot machine, repeat the above steps, and result will be the same. Reboot machine again, and just mount one partition, then doing "rm -rf *" without involve the second partition, rm will finish quickly. Has anyone obseved this behave on 8.0-RC? -Jin From egrosbein at rdtc.ru Wed Nov 18 08:20:49 2009 From: egrosbein at rdtc.ru (Eugene Grosbein) Date: Wed Nov 18 08:20:57 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B03A613.8060708@FreeBSD.org> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <4B03A613.8060708@FreeBSD.org> Message-ID: <4B03AE5E.8060302@rdtc.ru> Alexander Motin wrote: > Eugene Grosbein wrote: >> Alexander Motin wrote: >> >>> Feedbacks are welcome as always. >> Today's RELENG_8 build is broken (my /usr/src is symlink to /usr/local/src): > > Can you try to update your sources again? ahci driver in 8-STABLE and > HEAD are identical now and building fine in both, I've checked it > yesterday. I've updated again using cvsup.freebsd.org and now the problem has gone, world builds just fine. It seems my local mirror had wrong moment for update last night. Sorry for noise, I really should update again before posting. Thanks! Eugene Grosbein From gjin at ubicom.com Wed Nov 18 08:23:25 2009 From: gjin at ubicom.com (Guojun Jin) Date: Wed Nov 18 08:23:32 2009 Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive Message-ID: When mounting two partitions from a USB dirve, it can cause the drive access lock up for a long time. Details: Terminal 1 -- term1# mount /dev/da0s3d /mnt term1# cd /mnt ; rm -fr * when rm starts, go to terminal 2 and do: term2# mount /dev/da0s3e /dist ### this will hanging for a long time and USB hard drive activity light is off. After more than 1-2 minutes, mount returns, and the drive activity light is blinking, thus removing is going on. term2# ls /dist ### this will cause dUSB dirve hanging again -- no avtivity. Similarly, ls will finish in a couple of miniutes or longer, the rm command continues; but for a while, the drive activity will stop again. Reboot machine, repeat the above steps, and result will be the same. Reboot machine again, and just mount one partition, then doing "rm -rf *" without involve the second partition, rm will finish quickly. Has anyone obseved this behave on 8.0-RC? -Jin From gerrit at pmp.uni-hannover.de Wed Nov 18 09:17:09 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Wed Nov 18 09:17:16 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> On Tue, 17 Nov 2009 16:29:06 -0800 Freddie Cash wrote about Support for SAS/SATA non-RAID adapters: FC> Any recommendations on other SAS/SATA controllers to look at (just not FC> anything with MegaRAID in the name)? I installed a Supermicro AOC-USASLP-L8i card here some days ago. Should be even cheaper than the ones you mentioned and comes with a LSI chip supported by mpt driver: mpt0@pci0:6:0:0: class=0x010000 card=0xa68015d9 chip=0x00581000 rev=0x08 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS 3000 series, 8-port with 1068E -StorPort' class = mass storage subclass = SCSI I only installed it last week and cannot comment much on performance and stability up to now. cu Gerrit From andsux at gmail.com Wed Nov 18 09:35:43 2009 From: andsux at gmail.com (Andrei Antoukh) Date: Wed Nov 18 09:36:19 2009 Subject: Invitation to connect on LinkedIn Message-ID: <1229144206.498323.1258535266846.JavaMail.app@ech3-cdn11.prod> LinkedIn ------------ Andrei Antoukh requested to add you as a connection on LinkedIn: ------------------------------------------ Valeriy, I'd like to add you to my professional network on LinkedIn. - Andrei Accept invitation from Andrei Antoukh http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I34716907_4/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYQnPsMejoNdPgPiiYRdBASjRd5pyYSd3wUe30NdPwLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Andrei Antoukh http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I34716907_4/d5YTc3AScjsQcQALqnpPbOYWrSlI/svi/ ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/abq/inv-24/ ------ (c) 2009, LinkedIn Corporation From petefrench at ticketswitch.com Wed Nov 18 11:06:00 2009 From: petefrench at ticketswitch.com (Pete French) Date: Wed Nov 18 11:06:07 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: Message-ID: > better driver for this marvell chip. If someone gets to port it to > FreeBSD, the card may be pretty decent choice for those who have PCI-X > slot on-board. I have PCI-X and just purchased an unbranded card based on the SiL3124 chipset, as I was only using SATA 1 before. I didn't expect much, but it's actually suprisingly fast. Certainly a lot better than I expected - I've only had it a week, but so far I would recommend it. Mind you, this is my first real forray onto the world of non-SCSI controllers so if I just bought a nightmare chipset with loads of known issues then please tell me :-) -pete. From hselasky at c2i.net Wed Nov 18 11:12:04 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Nov 18 11:12:11 2009 Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive In-Reply-To: References: Message-ID: <200911181213.34112.hselasky@c2i.net> Hi, I'm not sure if this is an USB issue or not. If you get READ/WRITE errors and the drive simply dies then it might be the case. Else it is a system issue. There are quirks for mass storage which you can add to sys/dev/usb/storage/umass.c . --HPS On Wednesday 18 November 2009 08:33:07 Guojun Jin wrote: > Did newfs on those partition and made things worsen -- restore completely > fails: (I had experienced another similar problem on an IDE, which works > well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD 6.4. > > Is something new in 8.0 making disk partition schema changed? > > g_vfs_done():da0s3d[READ(offset=98304, length=16384)]error = 6 > g_vfs_done():da0s3d[WRITE(offset=192806912, length=16384)]error = 6 > fopen: Device not configured > cannot create save file ./restoresymtable for symbol table > abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status == > 0xa, scs i status == 0x0 > (da0:umass-sim0:0:0:0): removing device entry > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) > Device da0s3d went missing before all of the data could be written to it; > expect data loss. > > 99 23:19 sysinstall > 100 23:20 newfs /dev/da0s3d > 101 23:20 newfs /dev/da0s3e > 102 23:21 mount /dev/da0s3d /mnt > 103 23:21 cd /mnt > 104 23:21 dump -0f - /home | restore -rf - > 105 23:27 history 15 > > > > -----Original Message----- > From: Guojun Jin > Sent: Tue 11/17/2009 11:05 PM > To: freebsd-stable@freebsd.org > Cc: questions@freebsd.org; freebsd-usb@freebsd.org > Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive > > When mounting two partitions from a USB dirve, it can cause the drive > access lock up for a long time. Details: > > Terminal 1 -- > term1# mount /dev/da0s3d /mnt > term1# cd /mnt ; rm -fr * > > when rm starts, go to terminal 2 and do: > > term2# mount /dev/da0s3e /dist ### this will hanging for a long time and > USB hard drive activity light is off. After more than 1-2 minutes, mount > returns, and the drive activity light is blinking, thus removing is going > on. > > term2# ls /dist ### this will cause dUSB dirve hanging again -- no > avtivity. Similarly, ls will finish in a couple of miniutes or longer, the > rm command continues; but for a while, the drive activity will stop again. > > Reboot machine, repeat the above steps, and result will be the same. Reboot > machine again, and just mount one partition, then doing "rm -rf *" without > involve the second partition, rm will finish quickly. > > Has anyone obseved this behave on 8.0-RC? > > -Jin From thomas at ronner.org Wed Nov 18 11:19:17 2009 From: thomas at ronner.org (Thomas Ronner) Date: Wed Nov 18 11:19:23 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> Message-ID: On 18 Nov 2009, at 10:17, Gerrit K?hn wrote: > Supermicro AOC-USASLP-L8i card All my childhood traumas magically went away when I bought this card. Recommended! Thomas From freebsd at jdc.parodius.com Wed Nov 18 11:45:01 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Wed Nov 18 11:45:09 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: <20091118114459.GA9172@icarus.home.lan> On Wed, Nov 18, 2009 at 11:05:45AM +0000, Pete French wrote: > > better driver for this marvell chip. If someone gets to port it to > > FreeBSD, the card may be pretty decent choice for those who have PCI-X > > slot on-board. > > I have PCI-X and just purchased an unbranded card based > on the SiL3124 chipset, as I was only using SATA 1 before. > I didn't expect much, but it's actually suprisingly fast. > Certainly a lot better than I expected - I've only had it > a week, but so far I would recommend it. > > Mind you, this is my first real forray onto the world of non-SCSI > controllers so if I just bought a nightmare chipset with loads of > known issues then please tell me :-) I tend to avoid Silicon Image as a result of their 3112 snafu. I'm "generally" not that impressed by their 3114 and 3512 chips either, but the 3112 problem is severe. http://en.wikipedia.org/wiki/Silicon_Image_Inc.#Product_alerts The 3124 and later revisions are supposedly decent, but I've avoided them due to their history (I stick to Intel ICHx controllers + AHCI and don't bother with hardware RAID). Avoiding SIMG is difficult though, since they're used on most consumer and/or residential products, and are even more common when it comes to external hard drive enclosures (USB, Firewire, or otherwise) or similar devices. But it's the 3112 you have to watch out for. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd at jdc.parodius.com Wed Nov 18 11:54:18 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Wed Nov 18 11:54:25 2009 Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive In-Reply-To: <200911181213.34112.hselasky@c2i.net> References: <200911181213.34112.hselasky@c2i.net> Message-ID: <20091118115218.GB9172@icarus.home.lan> On Wed, Nov 18, 2009 at 12:13:32PM +0100, Hans Petter Selasky wrote: > I'm not sure if this is an USB issue or not. If you get READ/WRITE errors and > the drive simply dies then it might be the case. Else it is a system issue. The OP should be able to use smartmontools to obtain SMART stats from the SATA drive within the USB enclosure. The command will be somewhat funky, given that the drive is ATA but is mapped through CAM on FreeBSD and appears as a daX disk. I believe the following should work, but I have no way to test: smartctl --device=ata -a /dev/da0 You should check your console logs (dmesg) before and after running this command, as there may be sense key errors from CAM which can help determine if SMART is passed through or not. There's mention in the smartctl man page of a device type called "sat" which is an ATA<->SCSI emulation layer, but I believe it's the Linux equivalent of our CAM. Recent (in the past ~24 hours) commits to the RELENG_8 branch might provide native capability for smartctl to work without the --type argument, since mav@ has been improving the CAM layer to work with ATA disks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From eugen at grosbein.pp.ru Wed Nov 18 14:57:51 2009 From: eugen at grosbein.pp.ru (Eugene Grosbein) Date: Wed Nov 18 14:57:59 2009 Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive In-Reply-To: <20091118115218.GB9172@icarus.home.lan> References: <200911181213.34112.hselasky@c2i.net> <20091118115218.GB9172@icarus.home.lan> Message-ID: <4B040478.1020406@grosbein.pp.ru> Jeremy Chadwick wrote: > On Wed, Nov 18, 2009 at 12:13:32PM +0100, Hans Petter Selasky wrote: >> I'm not sure if this is an USB issue or not. If you get READ/WRITE errors and >> the drive simply dies then it might be the case. Else it is a system issue. > > The OP should be able to use smartmontools to obtain SMART stats from > the SATA drive within the USB enclosure. The command will be somewhat > funky, given that the drive is ATA but is mapped through CAM on FreeBSD > and appears as a daX disk. > > I believe the following should work, but I have no way to test: > > smartctl --device=ata -a /dev/da0 > > You should check your console logs (dmesg) before and after running > this command, as there may be sense key errors from CAM which can help > determine if SMART is passed through or not. > > There's mention in the smartctl man page of a device type called "sat" > which is an ATA<->SCSI emulation layer, but I believe it's the Linux > equivalent of our CAM. > > Recent (in the past ~24 hours) commits to the RELENG_8 branch might > provide native capability for smartctl to work without the --type > argument, since mav@ has been improving the CAM layer to work with ATA > disks. > Does not work for my external Seagate FreeAgent Go 500G USB2.0 drive %smartctl -a /dev/da0 smartctl version 5.38 [i386-portbld-freebsd8.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Device: Seagate FreeAgent Go Version: 102D Device type: disk Local Time is: Wed Nov 18 21:22:01 2009 KRAT Device does not support SMART Error Counter logging not supported Device does not support Self Test logging %smartctl --device=ata /dev/da0 smartctl version 5.38 [i386-portbld-freebsd8.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Smartctl: Device Read Identity Failed (not an ATA/ATAPI device) A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. %smartctl --device=ata -T permissive /dev/da0 smartctl version 5.38 [i386-portbld-freebsd8.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Smartctl: Device Read Identity Failed (not an ATA/ATAPI device) SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 82-83 don't show if SMART supported. A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options From jhb at freebsd.org Wed Nov 18 15:12:19 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 18 15:12:42 2009 Subject: boot issues In-Reply-To: References: Message-ID: <200911180941.01049.jhb@freebsd.org> On Wednesday 18 November 2009 2:19:45 am Randy Bush wrote: > [ this happened a month ago and i backed off ] > > i386, 7.2-stable from last summer > > cvsupped releng_7 > made and installed kernel > buildworld > boot -s > installworld > mergemaster > reboot > > hung after beastie, just as it did the other month > > booted -s > mount -2 / > /etc/rc.d/hostid start > /etc/rc.d/zfs start > looked around and all seemed ok > ^D > came up ok > > and that is how it is running now > > but why will it boot through -s and not from beastie? Err, so what happens if you break into the boot loader prompt (option 6 IIRC) and then just type 'boot', how far does it get before it hangs? -- John Baldwin From jhb at freebsd.org Wed Nov 18 15:12:19 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 18 15:12:43 2009 Subject: boot issues In-Reply-To: References: Message-ID: <200911180941.01049.jhb@freebsd.org> On Wednesday 18 November 2009 2:19:45 am Randy Bush wrote: > [ this happened a month ago and i backed off ] > > i386, 7.2-stable from last summer > > cvsupped releng_7 > made and installed kernel > buildworld > boot -s > installworld > mergemaster > reboot > > hung after beastie, just as it did the other month > > booted -s > mount -2 / > /etc/rc.d/hostid start > /etc/rc.d/zfs start > looked around and all seemed ok > ^D > came up ok > > and that is how it is running now > > but why will it boot through -s and not from beastie? Err, so what happens if you break into the boot loader prompt (option 6 IIRC) and then just type 'boot', how far does it get before it hangs? -- John Baldwin From fjwcash at gmail.com Wed Nov 18 16:22:59 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Nov 18 16:23:06 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118074329.GA13345@rink.nu> References: <20091118074329.GA13345@rink.nu> Message-ID: On Tue, Nov 17, 2009 at 11:43 PM, Rink Springer wrote: > On Tue, Nov 17, 2009 at 08:38:21PM -0800, Freddie Cash wrote: >> I've also found a couple of Areca cards (PCI-X, non-RAID/PCIe RAID), >> and have heard good things about Areca support in FreeBSD. ?Any >> comments on their quality/performance/reliability? > > I have got an Areca ARC-1110 4x SATA2 PCI-X card in my server, and I'm > quite impressed with the performance; these cards do very well in terms > I/O operations per second and the driver has been rock solid for me. The > only downside is that they are quite expensive (but well worth it, IMO) Compared to a 3Ware 9550SXU controller, these are cheap. The Areca is only $500 (open-box) or $700 (new) on newegg.ca. The 3Ware cards are over $1000, with the PCIe versions being over $1200 (which is what started me on this journey -- hardware budgets are getting smaller and smaller each year). -- Freddie Cash fjwcash@gmail.com From dkelly at hiwaay.net Wed Nov 18 16:39:59 2009 From: dkelly at hiwaay.net (David Kelly) Date: Wed Nov 18 16:40:12 2009 Subject: Invitation to connect on LinkedIn In-Reply-To: <1229144206.498323.1258535266846.JavaMail.app@ech3-cdn11.prod> References: <1229144206.498323.1258535266846.JavaMail.app@ech3-cdn11.prod> Message-ID: <20091118161317.GC7784@Grumpy.DynDNS.org> On Wed, Nov 18, 2009 at 01:07:46AM -0800, Andrei Antoukh wrote: > LinkedIn > ------------ > > Andrei Antoukh requested to add you as a connection on LinkedIn: > ------------------------------------------ Why isn't LinkedIn in FreeBSD.org's spam blocker? -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From fjwcash at gmail.com Wed Nov 18 16:56:15 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Nov 18 16:57:32 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> Message-ID: 2009/11/18 Gerrit K?hn : > On Tue, 17 Nov 2009 16:29:06 -0800 Freddie Cash wrote > about Support for SAS/SATA non-RAID adapters: > > FC> Any recommendations on other SAS/SATA controllers to look at (just not > FC> anything with MegaRAID in the name)? > > I installed a Supermicro AOC-USASLP-L8i card here some days ago. Should be > even cheaper than the ones you mentioned and comes with a LSI chip > supported by mpt driver: > > mpt0@pci0:6:0:0: ? ? ? ?class=0x010000 card=0xa68015d9 chip=0x00581000 > rev=0x08 hdr=0x00 vendor ? ? = 'LSI Logic (Was: Symbios Logic, NCR)' > ? ?device ? ? = 'SAS 3000 series, 8-port with 1068E -StorPort' > ? ?class ? ? ?= mass storage > ? ?subclass ? = SCSI > > I only installed it last week and cannot comment much on performance and > stability up to now. These look nice, and are in the $200-300 CDN range. Have the same mini-SAS connectors as the 3Ware cards we use, so wouldn't have to re-cable the chassis. Are you using these as standard disk controllers, or are you using the RAID features (seems it supports RAID0 and RAID1 in hardware, RAID5 in software)? Reading through the manual right now, and it doesn't cover using the card in non-RAID modes. Wondering if the drives would show up as normal da0 da1 da2 etc. All of these (there's a couple variations on the card) appear to be PCIe, though, no PCI-X. We have 24 drive bays, and only 2 PCIe slots. Have 3 PCI-X slots, though, so would need at least 1 PCI-X controller. -- Freddie Cash fjwcash@gmail.com From gerrit at pmp.uni-hannover.de Wed Nov 18 17:09:42 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?UTF-8?B?S8O8aG4=?=) Date: Wed Nov 18 17:09:50 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> Message-ID: <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> On Wed, 18 Nov 2009 08:56:14 -0800 Freddie Cash wrote about Re: Support for SAS/SATA non-RAID adapters: FC> > I installed a Supermicro AOC-USASLP-L8i card here some days ago. FC> > Should be even cheaper than the ones you mentioned and comes with a FC> > LSI chip supported by mpt driver: FC> > mpt0@pci0:6:0:0: ? ? ? ?class=0x010000 card=0xa68015d9 FC> > chip=0x00581000 rev=0x08 hdr=0x00 vendor ? ? = 'LSI Logic (Was: FC> > Symbios Logic, NCR)' device ? ? = 'SAS 3000 series, 8-port with FC> > 1068E -StorPort' class ? ? ?= mass storage FC> > ? ?subclass ? = SCSI FC> > I only installed it last week and cannot comment much on performance FC> > and stability up to now. FC> These look nice, and are in the $200-300 CDN range. Have the same FC> mini-SAS connectors as the 3Ware cards we use, so wouldn't have to FC> re-cable the chassis. Hm, I don't know the recent exchange rate, but are you sure this is the same card? I paid something like 80,-? (excl. VAT). FC> Are you using these as standard disk controllers, or are you using the FC> RAID features (seems it supports RAID0 and RAID1 in hardware, RAID5 in FC> software)? Reading through the manual right now, and it doesn't cover FC> using the card in non-RAID modes. Wondering if the drives would show FC> up as normal da0 da1 da2 etc. I think my card does not have the raid features included, maybe that's why it was so cheap. The devices appear as normal scsi disks: dmesg: da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) [...] cliff# camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 1 lun 0 (da1,pass1) at scbus0 target 2 lun 0 (da2,pass2) at scbus0 target 3 lun 0 (da3,pass3) at scbus0 target 4 lun 0 (da4,pass4) at scbus0 target 5 lun 0 (da5,pass5) at scbus0 target 6 lun 0 (da6,pass6) at scbus0 target 7 lun 0 (da7,pass7) FC> All of these (there's a couple variations on the card) appear to be FC> PCIe, though, no PCI-X. We have 24 drive bays, and only 2 PCIe slots. FC> Have 3 PCI-X slots, though, so would need at least 1 PCI-X FC> controller. I guess the version of the card I have here was actually intended to be used in some kind of special Supermirco-Extension Slot. However, it fits into a standard PCIe slot and works nicely there as far as I can tell. Do you have the opportunity of using a riser card that would give you one more slot? cu Gerrit From korvus at comcast.net Wed Nov 18 17:17:04 2009 From: korvus at comcast.net (Steve Polyack) Date: Wed Nov 18 17:17:12 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: <20091118074329.GA13345@rink.nu> Message-ID: <4B0428E6.6080900@comcast.net> Freddie Cash wrote: > On Tue, Nov 17, 2009 at 11:43 PM, Rink Springer wrote: > >> On Tue, Nov 17, 2009 at 08:38:21PM -0800, Freddie Cash wrote: >> >>> I've also found a couple of Areca cards (PCI-X, non-RAID/PCIe RAID), >>> and have heard good things about Areca support in FreeBSD. Any >>> comments on their quality/performance/reliability? >>> >> I have got an Areca ARC-1110 4x SATA2 PCI-X card in my server, and I'm >> quite impressed with the performance; these cards do very well in terms >> I/O operations per second and the driver has been rock solid for me. The >> only downside is that they are quite expensive (but well worth it, IMO) >> > > Compared to a 3Ware 9550SXU controller, these are cheap. The Areca is > only $500 (open-box) or $700 (new) on newegg.ca. The 3Ware cards are > over $1000, with the PCIe versions being over $1200 (which is what > started me on this journey -- hardware budgets are getting smaller and > smaller each year). > > We've also tried the Areca cards with FreeBSD - the Areca ARC-1680IX-12-2G PCIe x8 card to be precise. It's a SAS/SATA RAID card. The performance was very impressive. MUCH better than the Dell PERC4/5/6s we were used to. The drivers also seemed to be rock solid (FreeBSD is even listed as a supported OS on the company's website). The feature-set of the card itself is also very rich... The one we tried had its own OOB management via serial port or dedicated 100mbps ethernet jack. It supports endless combinations of RAID arrays, volumes, and SMTP/SNMP alerts. From fjwcash at gmail.com Wed Nov 18 17:35:57 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Nov 18 17:37:06 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> Message-ID: 2009/11/18 Gerrit K?hn : > On Wed, 18 Nov 2009 08:56:14 -0800 Freddie Cash wrote > about Re: Support for SAS/SATA non-RAID adapters: > > FC> > I installed a Supermicro AOC-USASLP-L8i card here some days ago. > FC> > Should be even cheaper than the ones you mentioned and comes with a > FC> > LSI chip supported by mpt driver: > > FC> > mpt0@pci0:6:0:0: ? ? ? ?class=0x010000 card=0xa68015d9 > FC> > chip=0x00581000 rev=0x08 hdr=0x00 vendor ? ? = 'LSI Logic (Was: > FC> > Symbios Logic, NCR)' device ? ? = 'SAS 3000 series, 8-port with > FC> > 1068E -StorPort' class ? ? ?= mass storage > FC> > ? ?subclass ? = SCSI > > FC> > I only installed it last week and cannot comment much on performance > FC> > and stability up to now. > > FC> These look nice, and are in the $200-300 CDN range. ?Have the same > FC> mini-SAS connectors as the 3Ware cards we use, so wouldn't have to > FC> re-cable the chassis. > > Hm, I don't know the recent exchange rate, but are you sure this is the > same card? I paid something like 80,-? (excl. VAT). Oops, you're right, was reading the model numbers wrong. The LSI1068-based one is only $129 CDN, the Intel IOP-based ones are $200-300 CDN. Last time I checked the Euro was in the $1.50-2.00 CDN range. > FC> Are you using these as standard disk controllers, or are you using the > FC> RAID features (seems it supports RAID0 and RAID1 in hardware, RAID5 in > FC> software)? ?Reading through the manual right now, and it doesn't cover > FC> using the card in non-RAID modes. ?Wondering if the drives would show > FC> up as normal da0 da1 da2 etc. > > I think my card does not have the raid features included, maybe that's why > it was so cheap. The devices appear as normal scsi disks: > > dmesg: > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) > [...] Nice. Thanks for the output. > FC> All of these (there's a couple variations on the card) appear to be > FC> PCIe, though, no PCI-X. ?We have 24 drive bays, and only 2 PCIe slots. > FC> Have 3 PCI-X slots, though, so would need at least 1 PCI-X > FC> controller. > > I guess the version of the card I have here was actually intended to be > used in some kind of special Supermirco-Extension Slot. However, it fits > into a standard PCIe slot and works nicely there as far as I can tell. > Do you have the opportunity of using a riser card that would give you one > more slot? Urgh, I have yet to find a riser card that will plug into a Tyan motherboard and not cause issues. Due to all the issues we've had with riser cards in the past, we have sworn off all riser cards. For our 2U servers, we use low-profile cards to avoid risers. I'll keep looking for a PCI-X card. These look like they'll cover our PCIe needs. -- Freddie Cash fjwcash@gmail.com From bp at barryp.org Wed Nov 18 17:37:09 2009 From: bp at barryp.org (Barry Pederson) Date: Wed Nov 18 17:38:57 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> Message-ID: <4B0430BF.4010201@barryp.org> Gerrit K?hn wrote: > On Wed, 18 Nov 2009 08:56:14 -0800 Freddie Cash wrote > about Re: Support for SAS/SATA non-RAID adapters: > > FC> > I installed a Supermicro AOC-USASLP-L8i card here some days ago. > FC> > Should be even cheaper than the ones you mentioned and comes with a > FC> > LSI chip supported by mpt driver: > > > I guess the version of the card I have here was actually intended to be > used in some kind of special Supermirco-Extension Slot. However, it fits > into a standard PCIe slot and works nicely there as far as I can tell. > Do you have the opportunity of using a riser card that would give you one > more slot? Those Supermicro UIO cards look like backwards PCIe cards. Do they come with other brackets for fitting into a PCIe slot, or did you have to go bracketless? The online manual at http://www.supermicro.com/manuals/other/AOC-USASLP-L8i.pdf didn't mention anything about brackets or how it'd work in PCIe slots. Barry From brian at brianwhalen.net Wed Nov 18 17:51:51 2009 From: brian at brianwhalen.net (Brian Whalen) Date: Wed Nov 18 17:51:59 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: <20091118074329.GA13345@rink.nu> Message-ID: <4B043434.8090809@brianwhalen.net> Freddie Cash wrote: > On Tue, Nov 17, 2009 at 11:43 PM, Rink Springer wrote: >> On Tue, Nov 17, 2009 at 08:38:21PM -0800, Freddie Cash wrote: >>> I've also found a couple of Areca cards (PCI-X, non-RAID/PCIe RAID), >>> and have heard good things about Areca support in FreeBSD. Any >>> comments on their quality/performance/reliability? >> I have got an Areca ARC-1110 4x SATA2 PCI-X card in my server, and I'm >> quite impressed with the performance; these cards do very well in terms >> I/O operations per second and the driver has been rock solid for me. The >> only downside is that they are quite expensive (but well worth it, IMO) > > Compared to a 3Ware 9550SXU controller, these are cheap. The Areca is > only $500 (open-box) or $700 (new) on newegg.ca. The 3Ware cards are > over $1000, with the PCIe versions being over $1200 (which is what > started me on this journey -- hardware budgets are getting smaller and > smaller each year). > The 3ware cards are not that expensive unless you need a truckload of ports. For the 9650SE on newegg.com; 2 port is 185 4 port is 324 8 port is 525 12 port is 669 Where are you getting the 1200 dollar price from? From freebsd at jdc.parodius.com Wed Nov 18 18:00:30 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Wed Nov 18 18:00:38 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <4B0430BF.4010201@barryp.org> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> <4B0430BF.4010201@barryp.org> Message-ID: <20091118180027.GA16477@icarus.home.lan> On Wed, Nov 18, 2009 at 11:37:03AM -0600, Barry Pederson wrote: > Gerrit K?hn wrote: > >On Wed, 18 Nov 2009 08:56:14 -0800 Freddie Cash wrote > >about Re: Support for SAS/SATA non-RAID adapters: > > > >FC> > I installed a Supermicro AOC-USASLP-L8i card here some days ago. > >FC> > Should be even cheaper than the ones you mentioned and comes with a > >FC> > LSI chip supported by mpt driver: > > > > > >I guess the version of the card I have here was actually intended to be > >used in some kind of special Supermirco-Extension Slot. However, it fits > >into a standard PCIe slot and works nicely there as far as I can tell. > >Do you have the opportunity of using a riser card that would give you one > >more slot? > > Those Supermicro UIO cards look like backwards PCIe cards. Do they > come with other brackets for fitting into a PCIe slot, or did you > have to go bracketless? > > The online manual at > > http://www.supermicro.com/manuals/other/AOC-USASLP-L8i.pdf > > didn't mention anything about brackets or how it'd work in PCIe slots. Supermicro UIO slots will adapt to whatever adapter you stick in them which are labelled compatible with said motherboard. The UIO slot itself is proprietary, but provides pinout interfaces to support both PCIe 1x, 4x, and 8x, as well as PCI (32-bit and 64-bit), and PCI-X (presumably 100 and 133MHz). But ultimately it depends on what board offers what pinouts through the UIO slot. Rather than "document it", here's how it works in the Real World(tm): - We need a PCIe x8 on our X7SBi for a low-profile RAID card - X7SBi motherboard has a UIO slot: http://www.supermicro.com/products/motherboard/Xeon3000/3210/X7SBA.cfm - UIO slot on this board supports one of the following, depending on which riser you buy: - (1) PCIe x8 - (1) PCI-X 133MHz (64-bit). - Scroll down to the bottom of the page and you'll find: - CSE-RR1U-ELi -- 1U PCI-E x8 Riser Card for X7SBi - Visit Supermicro's Accessories page, and select Riser Cards: http://www.supermicro.com/support/resources/Riser/riser.aspx - Search for CSE-RR1U-ELi, and you find: http://www.supermicro.com/a_images/products/Accessories/CSE-RR1U-ELi.jpg - Contact Supermicro distributor (whoever you got the server from, or you can contact Supermicro directly to help find a distributor for you) and get the CSE-RR1U-ELi. Some online retailers do sell these risers too. - Costs about US$11. - Buy it, install it, mount the card in it, enjoy. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd at jdc.parodius.com Wed Nov 18 18:10:10 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Wed Nov 18 18:11:20 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118180027.GA16477@icarus.home.lan> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> <4B0430BF.4010201@barryp.org> <20091118180027.GA16477@icarus.home.lan> Message-ID: <20091118181008.GA16741@icarus.home.lan> On Wed, Nov 18, 2009 at 10:00:27AM -0800, Jeremy Chadwick wrote: > On Wed, Nov 18, 2009 at 11:37:03AM -0600, Barry Pederson wrote: > > Gerrit K?hn wrote: > > >On Wed, 18 Nov 2009 08:56:14 -0800 Freddie Cash wrote > > >about Re: Support for SAS/SATA non-RAID adapters: > > > > > >FC> > I installed a Supermicro AOC-USASLP-L8i card here some days ago. > > >FC> > Should be even cheaper than the ones you mentioned and comes with a > > >FC> > LSI chip supported by mpt driver: > > > > > > > > >I guess the version of the card I have here was actually intended to be > > >used in some kind of special Supermirco-Extension Slot. However, it fits > > >into a standard PCIe slot and works nicely there as far as I can tell. > > >Do you have the opportunity of using a riser card that would give you one > > >more slot? > > > > Those Supermicro UIO cards look like backwards PCIe cards. Do they > > come with other brackets for fitting into a PCIe slot, or did you > > have to go bracketless? > > > > The online manual at > > > > http://www.supermicro.com/manuals/other/AOC-USASLP-L8i.pdf > > > > didn't mention anything about brackets or how it'd work in PCIe slots. > > Supermicro UIO slots will adapt to whatever adapter you stick in them > which are labelled compatible with said motherboard. > > The UIO slot itself is proprietary, but provides pinout interfaces > to support both PCIe 1x, 4x, and 8x, as well as PCI (32-bit and > 64-bit), and PCI-X (presumably 100 and 133MHz). But ultimately it > depends on what board offers what pinouts through the UIO slot. > > Rather than "document it", here's how it works in the Real World(tm): > > - We need a PCIe x8 on our X7SBi for a low-profile RAID card > - X7SBi motherboard has a UIO slot: > http://www.supermicro.com/products/motherboard/Xeon3000/3210/X7SBA.cfm > - UIO slot on this board supports one of the following, depending > on which riser you buy: > - (1) PCIe x8 > - (1) PCI-X 133MHz (64-bit). > - Scroll down to the bottom of the page and you'll find: > - CSE-RR1U-ELi -- 1U PCI-E x8 Riser Card for X7SBi > - Visit Supermicro's Accessories page, and select Riser Cards: > http://www.supermicro.com/support/resources/Riser/riser.aspx > - Search for CSE-RR1U-ELi, and you find: > http://www.supermicro.com/a_images/products/Accessories/CSE-RR1U-ELi.jpg > - Contact Supermicro distributor (whoever you got the server from, or > you can contact Supermicro directly to help find a distributor for > you) and get the CSE-RR1U-ELi. Some online retailers do sell these > risers too. > - Costs about US$11. > - Buy it, install it, mount the card in it, enjoy. By the way, I'll add that the AOC-USASLP-L8i is **not** compatible with the UIO riser/adapter for the X7SBi. This should be apparent just from examining the location of the PCIe x8 slot on the RAID card vs. where the CSE-RR1U-ELi PCIe x8 slot is located. You'll find what boards the AOC-USASLP-L8i is compatible with, UIO riser-wise, here: http://www.supermicro.com/products/accessories/addon/AOC-USASLP-L8i.cfm So in general, make sure whatever Supermicro card (RAID, Ethernet, SAS, SCSI, whatever) you're going with is indeed compatible with whatever Supermicro board you stick it in. Best thing to do is contact Supermicro Technical Support and ask. Their TS folks are better than average; I can get full specifications for ICs out of them, while I've never been able to achieve this with Tyan. Rackable (who uses Tyan mainboards) might have better luck. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pusateri at bangj.com Wed Nov 18 18:40:39 2009 From: pusateri at bangj.com (Tom Pusateri) Date: Wed Nov 18 18:40:47 2009 Subject: libdispatch on 8-Stable or 9-Current Message-ID: I've been trying to build the libdispatch port on FreeBSD 8-STABLE but not having much luck. I used the instructions here: http://wiki.freebsd.org/GCD They say to install 8.0-RC3 and then update the sources to FreeBSD 8-STABLE. I set my cvsup tag to: *default release=cvs tag=RELENG_8 and rebuilt the world but kern.osreldate didn't change. Its still 800107 which won't allow the port to build. Is there a different cvs tag I should be using or do I have to go to 9-CURRENT? Thanks, Tom From peterjeremy at acm.org Wed Nov 18 19:05:02 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Wed Nov 18 19:05:10 2009 Subject: Invitation to connect on LinkedIn In-Reply-To: <20091118161317.GC7784@Grumpy.DynDNS.org> References: <1229144206.498323.1258535266846.JavaMail.app@ech3-cdn11.prod> <20091118161317.GC7784@Grumpy.DynDNS.org> Message-ID: <20091118190458.GB68851@server.vk2pj.dyndns.org> On 2009-Nov-18 10:13:17 -0600, David Kelly wrote: >On Wed, Nov 18, 2009 at 01:07:46AM -0800, Andrei Antoukh wrote: >> LinkedIn >> ------------ >> >> Andrei Antoukh requested to add you as a connection on LinkedIn: >> ------------------------------------------ > >Why isn't LinkedIn in FreeBSD.org's spam blocker? I have raised this with postmaster@ and he is investigating how to block this spam. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091118/29fedcb3/attachment.pgp From fjwcash at gmail.com Wed Nov 18 19:11:36 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Nov 18 19:11:44 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118181008.GA16741@icarus.home.lan> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> <4B0430BF.4010201@barryp.org> <20091118180027.GA16477@icarus.home.lan> <20091118181008.GA16741@icarus.home.lan> Message-ID: On Wed, Nov 18, 2009 at 10:10 AM, Jeremy Chadwick wrote: > By the way, I'll add that the AOC-USASLP-L8i is **not** compatible with > the UIO riser/adapter for the X7SBi. ?This should be apparent just from > examining the location of the PCIe x8 slot on the RAID card vs. ?where > the CSE-RR1U-ELi PCIe x8 slot is located. > > You'll find what boards the AOC-USASLP-L8i is compatible with, UIO > riser-wise, here: > > http://www.supermicro.com/products/accessories/addon/AOC-USASLP-L8i.cfm > > So in general, make sure whatever Supermicro card (RAID, Ethernet, SAS, > SCSI, whatever) you're going with is indeed compatible with whatever > Supermicro board you stick it in. > > Best thing to do is contact Supermicro Technical Support and ask. ?Their > TS folks are better than average; I can get full specifications for ICs > out of them, while I've never been able to achieve this with Tyan. > Rackable (who uses Tyan mainboards) might have better luck. ?:-) Ah, in that case, it's not a solution for us. We use Tyan motherboards for pretty much everything, and have never had any luck with any kind of riser card, whether it be in a standard PCI slot or a PCI-X slot. -- Freddie Cash fjwcash@gmail.com From fjwcash at gmail.com Wed Nov 18 19:14:26 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Nov 18 19:14:33 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <4B043434.8090809@brianwhalen.net> References: <20091118074329.GA13345@rink.nu> <4B043434.8090809@brianwhalen.net> Message-ID: On Wed, Nov 18, 2009 at 9:51 AM, Brian Whalen wrote: > Freddie Cash wrote: >> On Tue, Nov 17, 2009 at 11:43 PM, Rink Springer wrote: >>> On Tue, Nov 17, 2009 at 08:38:21PM -0800, Freddie Cash wrote: >>>> I've also found a couple of Areca cards (PCI-X, non-RAID/PCIe RAID), >>>> and have heard good things about Areca support in FreeBSD. ?Any >>>> comments on their quality/performance/reliability? >>> >>> I have got an Areca ARC-1110 4x SATA2 PCI-X card in my server, and I'm >>> quite impressed with the performance; these cards do very well in terms >>> I/O operations per second and the driver has been rock solid for me. The >>> only downside is that they are quite expensive (but well worth it, IMO) >> >> Compared to a 3Ware 9550SXU controller, these are cheap. ?The Areca is >> only $500 (open-box) or $700 (new) on newegg.ca. ?The 3Ware cards are >> over $1000, with the PCIe versions being over $1200 (which is what >> started me on this journey -- hardware budgets are getting smaller and >> smaller each year). > > The 3ware cards are not that expensive unless you need a truckload of ports. > > For the 9650SE on newegg.com; > 2 port is 185 > 4 port is 324 > 8 port is 525 > 12 port is 669 > > Where are you getting the 1200 dollar price from? We deal in Canadian dollars. :) Our hardware purchaser spent several hours on the phone and web looking for a replacement 9650SE-12ML (12-port, multi-lane, PCIe). Every place she checked showed them as $1000-1200. We need the -12ML (or -16ML) for one server, as it's actually using the RAID features, and the controller in that server died (scorch marks on the heat sink). As that server was using RAID6, we couldn't replace it with any of the 9550s we have as spares. :( We have three servers using these cards. Only 1 is actually using the RAID features. The other two are ZFS storage servers. Going forward, we will be putting in more ZFS systems than non-ZFS systems, so we don't need as fancy of controller. Just lots of ports (or lots of cards, we have 3 PCI-X and 2 PCIe slots to work with). -- Freddie Cash fjwcash@gmail.com From bp at barryp.org Wed Nov 18 19:16:03 2009 From: bp at barryp.org (Barry Pederson) Date: Wed Nov 18 19:16:09 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091118181008.GA16741@icarus.home.lan> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> <4B0430BF.4010201@barryp.org> <20091118180027.GA16477@icarus.home.lan> <20091118181008.GA16741@icarus.home.lan> Message-ID: <4B0447EF.1080703@barryp.org> Jeremy Chadwick wrote: >> The UIO slot itself is proprietary, but provides pinout interfaces >> to support both PCIe 1x, 4x, and 8x, as well as PCI (32-bit and >> 64-bit), and PCI-X (presumably 100 and 133MHz). But ultimately it >> depends on what board offers what pinouts through the UIO slot. >> >> Rather than "document it", here's how it works in the Real World(tm): >> >> - We need a PCIe x8 on our X7SBi for a low-profile RAID card >> - X7SBi motherboard has a UIO slot: >> http://www.supermicro.com/products/motherboard/Xeon3000/3210/X7SBA.cfm >> - UIO slot on this board supports one of the following, depending >> on which riser you buy: >> - (1) PCIe x8 >> - (1) PCI-X 133MHz (64-bit). >> - Scroll down to the bottom of the page and you'll find: >> - CSE-RR1U-ELi -- 1U PCI-E x8 Riser Card for X7SBi >> - Visit Supermicro's Accessories page, and select Riser Cards: >> http://www.supermicro.com/support/resources/Riser/riser.aspx >> - Search for CSE-RR1U-ELi, and you find: >> http://www.supermicro.com/a_images/products/Accessories/CSE-RR1U-ELi.jpg >> - Contact Supermicro distributor (whoever you got the server from, or >> you can contact Supermicro directly to help find a distributor for >> you) and get the CSE-RR1U-ELi. Some online retailers do sell these >> risers too. >> - Costs about US$11. >> - Buy it, install it, mount the card in it, enjoy. > > By the way, I'll add that the AOC-USASLP-L8i is **not** compatible with > the UIO riser/adapter for the X7SBi. This should be apparent just from > examining the location of the PCIe x8 slot on the RAID card vs. where > the CSE-RR1U-ELi PCIe x8 slot is located. > > You'll find what boards the AOC-USASLP-L8i is compatible with, UIO > riser-wise, here: > > http://www.supermicro.com/products/accessories/addon/AOC-USASLP-L8i.cfm > > So in general, make sure whatever Supermicro card (RAID, Ethernet, SAS, > SCSI, whatever) you're going with is indeed compatible with whatever > Supermicro board you stick it in. > > Best thing to do is contact Supermicro Technical Support and ask. Their > TS folks are better than average; I can get full specifications for ICs > out of them, while I've never been able to achieve this with Tyan. > Rackable (who uses Tyan mainboards) might have better luck. :-) Thanks for the info. I have no doubt a Supermicro HBA will work in a Supermicro motherboard and chassis given the correct Supermicro risers or other accessories. What I was questioning was where the OP said: "it fits into a standard PCIe slot and works nicely there as far as I can tell" - which to me sounds like you could use this HBA in a *NON-Supermicro* motherboard. I was just wondering if that was truly the case, given how in the photos it looks to be arranged physically backwards from a regular PCIe card, and given how you mention "The UIO slot itself is proprietary". But some more digging on Google has turned up a few mentions along the lines of: """ This card plugs into a normal PCIe 8x slot but the metal mounting bracket bolted to the card is made for a UIO slot (which is why it's so cheap). All you have to do is remove the metal bracket and zip-tie the card to your case for mechanical support. Electrically it'll work fine in a PCIe x8 or x16 slot. """ If someone wanted to make PCIe compatible brackets for this affordable card, they'd probably sell a fair number to small shops or home users. Barry From jonathan at kc8onw.net Wed Nov 18 19:17:39 2009 From: jonathan at kc8onw.net (Jonathan) Date: Wed Nov 18 19:17:46 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: Message-ID: <4B044854.2080300@kc8onw.net> On 11/17/2009 7:29 PM, Freddie Cash wrote: > LSI SAS 3081E-R 8-port SAS/SATA PCIe I've had excellent luck with LSI cards in a moderate usage home environment. I've had the 3041 and 3081 and never had any issues with either card. I've never really stress tested them for performance with anything other than doing a zpool scrub on them but they've handled everything I've tried to do just fine. Hot swap also works correctly. Jonathan From gjin at ubicom.com Wed Nov 18 20:11:32 2009 From: gjin at ubicom.com (Guojun Jin) Date: Wed Nov 18 20:11:39 2009 Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive In-Reply-To: <200911181213.34112.hselasky@c2i.net> References: <200911181213.34112.hselasky@c2i.net> Message-ID: It looks like a system issue since it also happens to the SATA drive. The USB drive seems having more difficulty. I will back up rest partitions, Then redo the slice and partition to see if problem goes away. If so, then 8.0-R has a backward compatibility issue on the partition table or format to older FreeBSD release. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wednesday, November 18, 2009 3:14 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; freebsd-stable@freebsd.org; questions@freebsd.org Subject: Re: 8.0-RC3 USB lock up on mounting two partitions from one USB drive Hi, I'm not sure if this is an USB issue or not. If you get READ/WRITE errors and the drive simply dies then it might be the case. Else it is a system issue. There are quirks for mass storage which you can add to sys/dev/usb/storage/umass.c . --HPS On Wednesday 18 November 2009 08:33:07 Guojun Jin wrote: > Did newfs on those partition and made things worsen -- restore completely > fails: (I had experienced another similar problem on an IDE, which works > well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD 6.4. > > Is something new in 8.0 making disk partition schema changed? > > g_vfs_done():da0s3d[READ(offset=98304, length=16384)]error = 6 > g_vfs_done():da0s3d[WRITE(offset=192806912, length=16384)]error = 6 > fopen: Device not configured > cannot create save file ./restoresymtable for symbol table > abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status == > 0xa, scs i status == 0x0 > (da0:umass-sim0:0:0:0): removing device entry > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) > Device da0s3d went missing before all of the data could be written to it; > expect data loss. > > 99 23:19 sysinstall > 100 23:20 newfs /dev/da0s3d > 101 23:20 newfs /dev/da0s3e > 102 23:21 mount /dev/da0s3d /mnt > 103 23:21 cd /mnt > 104 23:21 dump -0f - /home | restore -rf - > 105 23:27 history 15 > > > > -----Original Message----- > From: Guojun Jin > Sent: Tue 11/17/2009 11:05 PM > To: freebsd-stable@freebsd.org > Cc: questions@freebsd.org; freebsd-usb@freebsd.org > Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive > > When mounting two partitions from a USB dirve, it can cause the drive > access lock up for a long time. Details: > > Terminal 1 -- > term1# mount /dev/da0s3d /mnt > term1# cd /mnt ; rm -fr * > > when rm starts, go to terminal 2 and do: > > term2# mount /dev/da0s3e /dist ### this will hanging for a long time and > USB hard drive activity light is off. After more than 1-2 minutes, mount > returns, and the drive activity light is blinking, thus removing is going > on. > > term2# ls /dist ### this will cause dUSB dirve hanging again -- no > avtivity. Similarly, ls will finish in a couple of miniutes or longer, the > rm command continues; but for a while, the drive activity will stop again. > > Reboot machine, repeat the above steps, and result will be the same. Reboot > machine again, and just mount one partition, then doing "rm -rf *" without > involve the second partition, rm will finish quickly. > > Has anyone obseved this behave on 8.0-RC? > > -Jin From mike at sentex.net Wed Nov 18 21:30:21 2009 From: mike at sentex.net (Mike Tancsa) Date: Wed Nov 18 21:30:29 2009 Subject: bug with some em nics on RELENG_7 Message-ID: <200911182130.nAILUJCR089766@lava.sentex.ca> On two Intel chipset Supermicro boards (X8STi and X8STE-0) using the onboard em nics (dmesg info below), I seem to have run into an issue where if I boot the box up with the cables unplugged, I cannot get the NICS to properly work post boot up. This is quite repeatable for me. So at boot time, I have # ifconfig em5 em5: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:d6:ef:13 inet 3.3.3.3 netmask 0xffffff00 broadcast 3.3.3.255 media: Ethernet autoselect status: no carrier I then ping something that would be across the wire while the nic is down. e.g. ping 3.3.3.1 I then plug in the cable so that the other side has 3.3.3.1 ifconfig shows all looks good # ifconfig em5 em5: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:d6:ef:13 inet 3.3.3.3 netmask 0xffffff00 broadcast 3.3.3.255 media: Ethernet autoselect (1000baseTX ) status: active I try and ping 3.3.3.1 which is on xover (via a switch shows the same behaviour), and no response to the pings.... BUT, I do see the MAC addr show up # ping -c 2 -S 3.3.3.3 3.3.3.1 PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes --- 3.3.3.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss # arp -na ? (3.3.3.1) at 00:30:48:94:88:20 on em5 [ethernet] ? (3.3.3.3) at 00:30:48:d6:ef:13 on em5 permanent [ethernet] I can see its mac addr ?!? Furthermore, if I do # ifconfig em5 3.3.3.55/32 alias On the other side, I see 0(ich10)# tcpdump -nei igb0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on igb0, link-type EN10MB (Ethernet), capture size 96 bytes 16:16:03.380886 00:30:48:d6:ef:13 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 3.3.3.55 tell 3.3.3.55, length 46 and I can ping if I specify the alias as the source IP # ping -S 3.3.3.55 3.3.3.1 PING 3.3.3.1 (3.3.3.1) from 3.3.3.55: 56 data bytes 64 bytes from 3.3.3.1: icmp_seq=0 ttl=64 time=0.184 ms 64 bytes from 3.3.3.1: icmp_seq=1 ttl=64 time=0.051 ms 64 bytes from 3.3.3.1: icmp_seq=2 ttl=64 time=0.055 ms 16:17:01.603345 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype ARP (0x0806), length 60: Reply 3.3.3.55 is-at 00:30:48:d6:ef:13, length 46 16:17:01.603349 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype IPv4 (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP echo reply, id 7946, seq 0, length 64 16:17:02.603497 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype IPv4 (0x0800), length 98: 3.3.3.55 > 3.3.3.1: ICMP echo request, id 7946, seq 1, length 64 16:17:02.603502 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype IPv4 (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP echo reply, id 7946, seq 1, length 64 16:17:03.604510 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype IPv4 (0x0800), length 98: 3.3.3.55 > 3.3.3.1: ICMP echo request, id 7946, seq 2, length 64 16:17:03.604516 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype IPv4 (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP echo reply, id 7946, seq 2, length 64 but not using the initial IP addr 0[iolite3A]# ping -S 3.3.3.3 3.3.3.1 PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes ^C --- 3.3.3.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss # Yet, # ping -S 3.3.3.3 3.3.3.1 PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes ^C --- 3.3.3.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss # ping -S 3.3.3.4 3.3.3.1 PING 3.3.3.1 (3.3.3.1) from 3.3.3.4: 56 data bytes 64 bytes from 3.3.3.1: icmp_seq=0 ttl=64 time=0.176 ms 64 bytes from 3.3.3.1: icmp_seq=1 ttl=64 time=0.050 ms ^C --- 3.3.3.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.050/0.113/0.176/0.063 ms Strange, eh ? em4@pci0:6:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em5@pci0:7:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em4: port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 em4: Using MSIX interrupts em4: [ITHREAD] em4: [ITHREAD] em4: [ITHREAD] em4: Ethernet address: 00:30:48:d6:ef:12 pcib7: irq 16 at device 28.1 on pci0 pci7: on pcib7 em5: port 0xec00-0xec1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 em5: Using MSIX interrupts em5: [ITHREAD] em5: [ITHREAD] em5: [ITHREAD] em5: Ethernet address: 00:30:48:d6:ef:13 The same does NOT happen with my external 2 port pcie nics (it says HP, but they are intel branded) eg em0@pci0:1:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) em1@pci0:1:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From tajudd at gmail.com Wed Nov 18 22:10:58 2009 From: tajudd at gmail.com (Tim Judd) Date: Wed Nov 18 22:11:12 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem In-Reply-To: <456530742.21066.1258437272093.JavaMail.apache@mail51.abv.bg> References: <456530742.21066.1258437272093.JavaMail.apache@mail51.abv.bg> Message-ID: On 11/16/09, Mario Pavlov wrote: > indeed you get bonus points if you firewall yourself :) > and of course this is not the first time I do that so my score is pretty > good > however my favourite is to forget about net.inet.ip.forwarding when I > upgrade routers with many clients :) > > Tim, thanks for your hints...but I don't understand this one: > >2nd, you buildworld and installworld into the diskless root, but never > >use it. You're using disk space you can reclaim. > how so I never use it and can reclaim diskspace ? The Monday's email you sent at 11:22 (by datestamp on gmail), you wrote: ================================================================================ mkdir /storage0/diskless cd /usr/src export DESTDIR=/storage0/diskless make buildworld buildkernel installworld distribution installkernel ================================================================================ ----------------------- You clearly 'make buildworld installworld' but your later exports have /storage0/diskless and /usr being exported. shouldn't it be either /storage0/diskless (as a root filesystem and everything underneath it) or if you want to unecessarily break it up, exporting /storage0/diskless/usr ? Understand? From doconnor at gsoft.com.au Wed Nov 18 22:15:32 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Nov 18 22:15:39 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <4AFF40B1.3040705@gsoft.com.au> References: <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> Message-ID: <200911190845.24313.doconnor@gsoft.com.au> On Sun, 15 Nov 2009, Daniel O'Connor wrote: > > There's no need to detach anything. > > I'll try it when I get home and see how it goes. How can I show what partition has what UUID? gpart list and gpart show do not say.. I suspect if I booted verbose glabel would say but that is a bit annoying :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091118/bfe86b92/attachment.pgp From marius at nuenneri.ch Wed Nov 18 23:11:49 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Wed Nov 18 23:11:57 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200911190845.24313.doconnor@gsoft.com.au> References: <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> <200911190845.24313.doconnor@gsoft.com.au> Message-ID: On Wed, Nov 18, 2009 at 23:15, Daniel O'Connor wrote: > On Sun, 15 Nov 2009, Daniel O'Connor wrote: >> ?> There's no need to detach anything. >> >> I'll try it when I get home and see how it goes. > > How can I show what partition has what UUID? > > gpart list and gpart show do not say.. > > I suspect if I booted verbose glabel would say but that is a bit > annoying :) % sysctl -b kern.geom.confdot | dot -Tpng > foo.png % pkg_which /usr/local/bin/dot graphviz-2.24.0_1 From roberto at keltia.freenix.fr Wed Nov 18 23:25:36 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Wed Nov 18 23:26:10 2009 Subject: libdispatch on 8-Stable or 9-Current In-Reply-To: References: Message-ID: <20091118232530.GA2780@ng.keltia.net> According to Tom Pusateri: > and rebuilt the world but kern.osreldate didn't change. Its still 800107 which won't allow the port to build. Change the <= into a < in libdispatch/Makefile and it will happily build the port. All tests pass. I'm using a fairly recent clang snapshot for the blocks support. llvm-devel-2.7.r89141 (made with "make BOOTSTRAP=yes makesum && update) libdispatch-147 compiler-rt-0.r83568 FreeBSD ng.keltia.net 8.0-PRERELEASE FreeBSD #6 r199493M: Wed Nov 18 22:33:04 CET 2009 From roberto at keltia.freenix.fr Wed Nov 18 23:32:14 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Wed Nov 18 23:32:20 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B03322A.2080608@FreeBSD.org> References: <4B03322A.2080608@FreeBSD.org> Message-ID: <20091118233210.GB2780@ng.keltia.net> According to Alexander Motin: > Feedbacks are welcome as always. Working fine from here, on a recent Dell T3500 with ICH8/ICH10 controllers (ATA/AHCI). Thanks a lot! Disks were renamed from ad{4,6,8} into ada{0,1,2}. I'm using a full-GPT-ZFS setup here. ZFS mounted all pools w/o any issue and seems to be using the gptids instead of the /dev/adNp3 partitions. Swap is not on ZFS but I added GPT labels with gpart and glabel added the /dev/gpt entries so swap is fine too. See below: ahci0: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf mem 0xff970000-0xff9707ff irq 20 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ... (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 (aprobe1:ahcich1:0:0:0): SIGNATURE: 0000 (aprobe2:ahcich2:0:0:0): SIGNATURE: 0000 (aprobe3:ahcich3:0:0:0): SIGNATURE: eb14 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) cd0 at ahcich3 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: Command Queueing enabled ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA/ATAPI-8 SATA 2.x device ada2: 300.000MB/s transfers ada2: Command Queueing enabled ada2: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) 411 [0:31] roberto@ng:~> swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/swap0 4194304 0 4194304 0% /dev/gpt/swap1 4194304 0 4194304 0% /dev/gpt/swap2 4194304 0 4194304 0% Total 12582912 0 12582912 0% From roberto at keltia.freenix.fr Wed Nov 18 23:35:00 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Wed Nov 18 23:35:07 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <20091118061726.GA1675@icarus.home.lan> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> Message-ID: <20091118233457.GC2780@ng.keltia.net> According to Jeremy Chadwick: > I didn't have this problem. System has AHCI in use, and the kernel is > built to make use of modular atacore. Specifically: > > # Modular ATA > device atacore # Core ATA functionality > device ataisa # ISA bus support > device atapci # PCI bus support; only generic chipset support > device ataahci # AHCI SATA > device ataintel # Intel Interesting. My own kernel config file has the following and ahci.ko is loaded by loader.conf. Do I need to change my config to match your own? ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) From jfvogel at gmail.com Thu Nov 19 00:29:19 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Nov 19 00:29:28 2009 Subject: bug with some em nics on RELENG_7 In-Reply-To: <200911182130.nAILUJCR089766@lava.sentex.ca> References: <200911182130.nAILUJCR089766@lava.sentex.ca> Message-ID: <2a41acea0911181629r4eb1a199we28a94a82ec67cf@mail.gmail.com> Hey Mike, Can you check if you see the same behavior on RELENG 8? There is a systemic problem having to do with when to enable interrupts that might be behind this. The em driver does not enable them until em_init_locked(), this is because until then its not ready to deal with a TX or RX interrupt. However, this means that a Link interrupt also will not be seen, BUT, and here is where it gets a bit funny, an call to check link happens in attach, it will be either true or false, AND, even if you remove or add a cable after that point, until interrupts are enabled the state will not change. In the days before MSIX one interrupt was for everything so it was impossible to change this without a radical rework to the driver design, but I suppose it would be possible with MSIX to selectively enable the link one earlier, I seem to recall discussions with our Linux crew that made me decide not to pursue that (its of limited value really). Not sure why this happens on Hartwell (82574) and not on 82571, that's an interesting bit, the 82574 is the ONLY interface in the em driver that has MSIX support, unfortunately its kinda hacked in, but it did not really fit into the igb driver either for various technical reasons. What if you boot up, then do NOT ping or anything until the interface is assigned an address (and so init is run), and the cable is plugged in. If that happens first does it work? Do let me know if you can check on 8, if not I can have my validation engineer try this. Best regards, Jack On Wed, Nov 18, 2009 at 1:30 PM, Mike Tancsa wrote: > > On two Intel chipset Supermicro boards (X8STi and X8STE-0) using the > onboard em nics (dmesg info below), I seem to have run into an issue where > if I boot the box up with the cables unplugged, I cannot get the NICS to > properly work post boot up. This is quite repeatable for me. So at boot > time, I have > > # ifconfig em5 > em5: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:30:48:d6:ef:13 > inet 3.3.3.3 netmask 0xffffff00 broadcast 3.3.3.255 > media: Ethernet autoselect > status: no carrier > > > I then ping something that would be across the wire while the nic is down. > e.g. ping 3.3.3.1 > > I then plug in the cable so that the other side has 3.3.3.1 > > ifconfig shows all looks good > > # ifconfig em5 > em5: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:30:48:d6:ef:13 > inet 3.3.3.3 netmask 0xffffff00 broadcast 3.3.3.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > I try and ping 3.3.3.1 which is on xover (via a switch shows the same > behaviour), and no response to the pings.... BUT, I do see the MAC addr show > up > # ping -c 2 -S 3.3.3.3 3.3.3.1 > PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes > > --- 3.3.3.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > # arp -na > ? (3.3.3.1) at 00:30:48:94:88:20 on em5 [ethernet] > ? (3.3.3.3) at 00:30:48:d6:ef:13 on em5 permanent [ethernet] > > I can see its mac addr ?!? > > Furthermore, if I do > > # ifconfig em5 3.3.3.55/32 alias > > On the other side, I see > > 0(ich10)# tcpdump -nei igb0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on igb0, link-type EN10MB (Ethernet), capture size 96 bytes > 16:16:03.380886 00:30:48:d6:ef:13 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: Request who-has 3.3.3.55 tell 3.3.3.55, length 46 > > > and I can ping if I specify the alias as the source IP > > # ping -S 3.3.3.55 3.3.3.1 > PING 3.3.3.1 (3.3.3.1) from 3.3.3.55: 56 data bytes > 64 bytes from 3.3.3.1: icmp_seq=0 ttl=64 time=0.184 ms > 64 bytes from 3.3.3.1: icmp_seq=1 ttl=64 time=0.051 ms > 64 bytes from 3.3.3.1: icmp_seq=2 ttl=64 time=0.055 ms > > > > 16:17:01.603345 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype ARP > (0x0806), length 60: Reply 3.3.3.55 is-at 00:30:48:d6:ef:13, length 46 > 16:17:01.603349 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype IPv4 > (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP echo reply, id 7946, seq 0, > length 64 > 16:17:02.603497 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype IPv4 > (0x0800), length 98: 3.3.3.55 > 3.3.3.1: ICMP echo request, id 7946, seq > 1, length 64 > 16:17:02.603502 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype IPv4 > (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP echo reply, id 7946, seq 1, > length 64 > 16:17:03.604510 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype IPv4 > (0x0800), length 98: 3.3.3.55 > 3.3.3.1: ICMP echo request, id 7946, seq > 2, length 64 > 16:17:03.604516 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype IPv4 > (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP echo reply, id 7946, seq 2, > length 64 > > > > but not using the initial IP addr > > 0[iolite3A]# ping -S 3.3.3.3 3.3.3.1 > PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes > ^C > --- 3.3.3.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > # > > Yet, > > # ping -S 3.3.3.3 3.3.3.1 > PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes > ^C > --- 3.3.3.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > # ping -S 3.3.3.4 3.3.3.1 > PING 3.3.3.1 (3.3.3.1) from 3.3.3.4: 56 data bytes > 64 bytes from 3.3.3.1: icmp_seq=0 ttl=64 time=0.176 ms > 64 bytes from 3.3.3.1: icmp_seq=1 ttl=64 time=0.050 ms > ^C > --- 3.3.3.1 ping statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.050/0.113/0.176/0.063 ms > > > Strange, eh ? > > > em4@pci0:6:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > em5@pci0:7:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > > em4: port 0xdc00-0xdc1f mem > 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 > em4: Using MSIX interrupts > em4: [ITHREAD] > em4: [ITHREAD] > em4: [ITHREAD] > em4: Ethernet address: 00:30:48:d6:ef:12 > pcib7: irq 16 at device 28.1 on pci0 > pci7: on pcib7 > em5: port 0xec00-0xec1f mem > 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 > em5: Using MSIX interrupts > em5: [ITHREAD] > em5: [ITHREAD] > em5: [ITHREAD] > em5: Ethernet address: 00:30:48:d6:ef:13 > > The same does NOT happen with my external 2 port pcie nics (it says HP, but > they are intel branded) > eg > em0@pci0:1:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) > em1@pci0:1:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 rev=0x06 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) > > ---Mike > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From doconnor at gsoft.com.au Thu Nov 19 00:49:47 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Nov 19 00:49:55 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: <200911190845.24313.doconnor@gsoft.com.au> Message-ID: <200911191119.40243.doconnor@gsoft.com.au> On Thu, 19 Nov 2009, Marius N?nnerich wrote: > On Wed, Nov 18, 2009 at 23:15, Daniel O'Connor wrote: > > On Sun, 15 Nov 2009, Daniel O'Connor wrote: > >> ?> There's no need to detach anything. > >> > >> I'll try it when I get home and see how it goes. > > > > How can I show what partition has what UUID? > > > > gpart list and gpart show do not say.. > > > > I suspect if I booted verbose glabel would say but that is a bit > > annoying :) > > % sysctl -b kern.geom.confdot | dot -Tpng > foo.png > % pkg_which /usr/local/bin/dot > graphviz-2.24.0_1 Ahah, of course, thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091119/3b779a41/attachment.pgp From doconnor at gsoft.com.au Thu Nov 19 00:53:14 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Nov 19 00:53:21 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <4AFF40B1.3040705@gsoft.com.au> References: <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> Message-ID: <200911191123.08870.doconnor@gsoft.com.au> On Sun, 15 Nov 2009, Daniel O'Connor wrote: > > There's no need to detach anything. > > I'll try it when I get home and see how it goes. Unfortunately I get.. [midget 11:20] ~ >sudo zpool replace tank ad4p2 gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc cannot use '/dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc': must be a GEOM provider or regular file [midget 11:20] ~ >ll /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc crw-r----- 1 root operator 0, 164 Oct 21 15:34 /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091119/58abb912/attachment.pgp From mike at sentex.net Thu Nov 19 02:23:13 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 19 02:23:21 2009 Subject: bug with some em nics on RELENG_7 In-Reply-To: <2a41acea0911181629r4eb1a199we28a94a82ec67cf@mail.gmail.com > References: <200911182130.nAILUJCR089766@lava.sentex.ca> <2a41acea0911181629r4eb1a199we28a94a82ec67cf@mail.gmail.com> Message-ID: <200911190223.nAJ2NCFL091290@lava.sentex.ca> At 07:29 PM 11/18/2009, Jack Vogel wrote: >Hey Mike, > >Can you check if you see the same behavior on RELENG 8? Hi Jack, Yes, I will reboot the hardware with a RELENG_8 image tomorrow to test >Not sure why this happens on Hartwell (82574) and not on 82571, that's >an interesting bit, the 82574 is the ONLY interface in the em driver that >has MSIX support, unfortunately its kinda hacked in, but it did not really >fit into the igb driver either for various technical reasons. Is this the "FILTER" vs "ITHREAD" ? Is there a way to force this chipset to use the same logic as 82571s ? # dmesg |grep ^em em0: port 0xbc00-0xbc1f mem 0xface0000-0xfacfffff,0xfacc0000-0xfacdffff irq 16 at device 0.0 on pci1 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:78:e6:e0 em1: port 0xb880-0xb89f mem 0xfac80000-0xfac9ffff,0xfac60000-0xfac7ffff irq 17 at device 0.1 on pci1 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:78:e6:e1 em2: port 0xcc00-0xcc1f mem 0xfade0000-0xfadfffff,0xfadc0000-0xfaddffff irq 16 at device 0.0 on pci3 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:cf:26:de em3: port 0xc880-0xc89f mem 0xfad80000-0xfad9ffff,0xfad60000-0xfad7ffff irq 17 at device 0.1 on pci3 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:15:17:cf:26:df em4: port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 em4: Using MSIX interrupts em4: [ITHREAD] em4: [ITHREAD] em4: [ITHREAD] em4: Ethernet address: 00:30:48:d6:ef:12 em5: port 0xec00-0xec1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 em5: Using MSIX interrupts em5: [ITHREAD] em5: [ITHREAD] em5: [ITHREAD] em5: Ethernet address: 00:30:48:d6:ef:13 >What if you boot up, then do NOT ping or anything until the interface is >assigned an address (and so init is run), and the cable is plugged in. If >that happens first does it work? yes. If I have the cables plugged in and reboot the box, its ok. I am pretty sure all is ok if I boot it up, with no address assigned, plug the cables in, and then assign addr. I havent tested it out yet, but not sure how things play out when the ports are connected to a switch that is not in portfast mode, so the carrier does not always come up right away. The other thing I saw was that the NIC was getting stuck with the carrier showing up, even though cable was unplugged. However, I was not able to find the exact conditions this happened. >Do let me know if you can check on 8, if not I can have my validation >engineer try this. I will report back tomorrow. ---Mike >Best regards, > >Jack > > >On Wed, Nov 18, 2009 at 1:30 PM, Mike Tancsa ><mike@sentex.net> wrote: > >On two Intel chipset Supermicro boards (X8STi and X8STE-0) using the >onboard em nics (dmesg info below), I seem to have run into an issue >where if I boot the box up with the cables unplugged, I cannot get >the NICS to properly work post boot up. This is quite repeatable >for me. So at boot time, I have > ># ifconfig em5 >em5: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:30:48:d6:ef:13 > inet 3.3.3.3 netmask 0xffffff00 broadcast 3.3.3.255 > media: Ethernet autoselect > status: no carrier > > >I then ping something that would be across the wire while the nic is >down. e.g. ping 3.3.3.1 > >I then plug in the cable so that the other side has 3.3.3.1 > >ifconfig shows all looks good > ># ifconfig em5 >em5: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:30:48:d6:ef:13 > inet 3.3.3.3 netmask 0xffffff00 broadcast 3.3.3.255 > media: Ethernet autoselect (1000baseTX ) > status: active > >I try and ping 3.3.3.1 which is on xover (via a switch shows the >same behaviour), and no response to the pings.... BUT, I do see the >MAC addr show up ># ping -c 2 -S 3.3.3.3 3.3.3.1 >PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes > >--- 3.3.3.1 ping statistics --- >2 packets transmitted, 0 packets received, 100.0% packet loss ># arp -na >? (3.3.3.1) at 00:30:48:94:88:20 on em5 [ethernet] >? (3.3.3.3) at 00:30:48:d6:ef:13 on em5 permanent [ethernet] > >I can see its mac addr ?!? > >Furthermore, if I do > ># ifconfig em5 3.3.3.55/32 alias > >On the other side, I see > >0(ich10)# tcpdump -nei igb0 >tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >listening on igb0, link-type EN10MB (Ethernet), capture size 96 bytes >16:16:03.380886 00:30:48:d6:ef:13 > ff:ff:ff:ff:ff:ff, ethertype ARP >(0x0806), length 60: Request who-has 3.3.3.55 tell 3.3.3.55, length 46 > > >and I can ping if I specify the alias as the source IP > ># ping -S 3.3.3.55 3.3.3.1 >PING 3.3.3.1 (3.3.3.1) from 3.3.3.55: 56 data bytes >64 bytes from 3.3.3.1: icmp_seq=0 ttl=64 time=0.184 ms >64 bytes from 3.3.3.1: icmp_seq=1 ttl=64 time=0.051 ms >64 bytes from 3.3.3.1: icmp_seq=2 ttl=64 time=0.055 ms > > > >16:17:01.603345 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype ARP >(0x0806), length 60: Reply 3.3.3.55 is-at 00:30:48:d6:ef:13, length 46 >16:17:01.603349 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype >IPv4 (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP >echo reply, id 7946, seq 0, length 64 >16:17:02.603497 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype >IPv4 (0x0800), length 98: 3.3.3.55 > 3.3.3.1: ICMP >echo request, id 7946, seq 1, length 64 >16:17:02.603502 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype >IPv4 (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP >echo reply, id 7946, seq 1, length 64 >16:17:03.604510 00:30:48:d6:ef:13 > 00:30:48:94:88:20, ethertype >IPv4 (0x0800), length 98: 3.3.3.55 > 3.3.3.1: ICMP >echo request, id 7946, seq 2, length 64 >16:17:03.604516 00:30:48:94:88:20 > 00:30:48:d6:ef:13, ethertype >IPv4 (0x0800), length 98: 3.3.3.1 > 3.3.3.55: ICMP >echo reply, id 7946, seq 2, length 64 > > > >but not using the initial IP addr > >0[iolite3A]# ping -S 3.3.3.3 3.3.3.1 >PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes >^C >--- 3.3.3.1 ping statistics --- >2 packets transmitted, 0 packets received, 100.0% packet loss ># > >Yet, > ># ping -S 3.3.3.3 3.3.3.1 >PING 3.3.3.1 (3.3.3.1) from 3.3.3.3: 56 data bytes >^C >--- 3.3.3.1 ping statistics --- >2 packets transmitted, 0 packets received, 100.0% packet loss ># ping -S 3.3.3.4 3.3.3.1 >PING 3.3.3.1 (3.3.3.1) from 3.3.3.4: 56 data bytes >64 bytes from 3.3.3.1: icmp_seq=0 ttl=64 time=0.176 ms >64 bytes from 3.3.3.1: icmp_seq=1 ttl=64 time=0.050 ms >^C >--- 3.3.3.1 ping statistics --- >2 packets transmitted, 2 packets received, 0.0% packet loss >round-trip min/avg/max/stddev = 0.050/0.113/0.176/0.063 ms > > >Strange, eh ? > > >em4@pci0:6:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 >rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled >em5@pci0:7:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 >rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled > > >em4: port 0xdc00-0xdc1f >mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 >em4: Using MSIX interrupts >em4: [ITHREAD] >em4: [ITHREAD] >em4: [ITHREAD] >em4: Ethernet address: 00:30:48:d6:ef:12 >pcib7: irq 16 at device 28.1 on pci0 >pci7: on pcib7 >em5: port 0xec00-0xec1f >mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 >em5: Using MSIX interrupts >em5: [ITHREAD] >em5: [ITHREAD] >em5: [ITHREAD] >em5: Ethernet address: 00:30:48:d6:ef:13 > >The same does NOT happen with my external 2 port pcie nics (it says >HP, but they are intel branded) >eg >em0@pci0:1:0:0: class=0x020000 card=0x115e8086 chip=0x105e8086 >rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) >em1@pci0:1:0:1: class=0x020000 card=0x115e8086 chip=0x105e8086 >rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) > > ---Mike > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex >Communications, >mike@sentex.net >Providing Internet since >1994 www.sentex.net >Cambridge, Ontario >Canada www.sentex.net/mike > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From egrosbein at rdtc.ru Thu Nov 19 03:18:36 2009 From: egrosbein at rdtc.ru (Eugene Grosbein) Date: Thu Nov 19 03:18:43 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <20091118061726.GA1675@icarus.home.lan> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> Message-ID: <4B04B908.1020505@rdtc.ru> Jeremy Chadwick wrote: > I didn't have this problem. System has AHCI in use, and the kernel is > built to make use of modular atacore. Specifically: > > # Modular ATA > device atacore # Core ATA functionality > device ataisa # ISA bus support > device atapci # PCI bus support; only generic chipset support > device ataahci # AHCI SATA > device ataintel # Intel How should STABLE user (not tracking freebsd-current@) learn about CAM ATA configuration? There is ahci(4) manual page in 8.0-PRERELEASE but no ada(4) that is linked here. I've just tried "Modular ATA" configuration of Intel ICH7-based system plus "device ahci" minus all traditional ata(4) kernel configuration, the kernel builds fine but boot messages do not show any attempt to detect my SATA HDD, so root mount just fails (I use GEOM UFS labels in my /etc/fstab). Typing ? at "mounroot" prompt I see only daX devices standing for my USB cardreader and no device for HDD. It seems I miss ada(4) device and I cannot find it in 8.0 - not ada.ko nor "device ada". Eugene Grosbein From freebsd at abv.bg Thu Nov 19 05:48:53 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Thu Nov 19 05:49:00 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem Message-ID: <314774211.102489.1258609764004.JavaMail.apache@mail53.abv.bg> oh yes, I got what you meant now true, I used /usr from the server because I wanted to have all my ports available to the client. Is there a nice way to install ports only in the diskless distribution ? thank you. Regards Mario >On 11/16/09, Mario Pavlov wrote: >> indeed you get bonus points if you firewall yourself :) >> and of course this is not the first time I do that so my score is pretty >> good >> however my favourite is to forget about net.inet.ip.forwarding when I >> upgrade routers with many clients :) >> >> Tim, thanks for your hints...but I don't understand this one: >> >2nd, you buildworld and installworld into the diskless root, but never >> >use it. You're using disk space you can reclaim. >> how so I never use it and can reclaim diskspace ? > > >The Monday's email you sent at 11:22 (by datestamp on gmail), you wrote: >================================================================================ >mkdir /storage0/diskless >cd /usr/src >export DESTDIR=/storage0/diskless >make buildworld buildkernel installworld distribution installkernel >================================================================================ > > >----------------------- >You clearly 'make buildworld installworld' but your later exports have >/storage0/diskless and /usr being exported. shouldn't it be either >/storage0/diskless (as a root filesystem and everything underneath it) >or if you want to unecessarily break it up, exporting >/storage0/diskless/usr ? > > >Understand? > ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From freebsd at jdc.parodius.com Thu Nov 19 05:50:27 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 19 05:50:34 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B04B908.1020505@rdtc.ru> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> <4B04B908.1020505@rdtc.ru> Message-ID: <20091119055025.GA30911@icarus.home.lan> On Thu, Nov 19, 2009 at 10:18:32AM +0700, Eugene Grosbein wrote: > Jeremy Chadwick wrote: > > > I didn't have this problem. System has AHCI in use, and the kernel is > > built to make use of modular atacore. Specifically: > > > > # Modular ATA > > device atacore # Core ATA functionality > > device ataisa # ISA bus support > > device atapci # PCI bus support; only generic chipset support > > device ataahci # AHCI SATA > > device ataintel # Intel > > How should STABLE user (not tracking freebsd-current@) learn about CAM ATA configuration? > There is ahci(4) manual page in 8.0-PRERELEASE but no ada(4) that is linked here. I don't know. I'm waiting for someone to actually write documentation on this. I keep seeing commits talking about ATA disks via CAM (e.g. SCSI emulation for ATA disks), but the only thing I'm aware of that exists is SCSI emulation for ATAPI devices. > I've just tried "Modular ATA" configuration of Intel ICH7-based system plus "device ahci" > minus all traditional ata(4) kernel configuration, the kernel builds fine > but boot messages do not show any attempt to detect my SATA HDD, > so root mount just fails (I use GEOM UFS labels in my /etc/fstab). > Typing ? at "mounroot" prompt I see only daX devices standing for my USB cardreader > and no device for HDD. This sounds like a different problem. You may want to talk to mav@ about this. > It seems I miss ada(4) device and I cannot find it in 8.0 - not ada.ko nor "device ada". Same. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From amvandemore at gmail.com Thu Nov 19 06:11:27 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Thu Nov 19 06:11:34 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <20091119055025.GA30911@icarus.home.lan> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> <4B04B908.1020505@rdtc.ru> <20091119055025.GA30911@icarus.home.lan> Message-ID: <6201873e0911182211o17368cc4p2b4cfc0d702cb203@mail.gmail.com> > > I don't know. I'm waiting for someone to actually write documentation > on this. I keep seeing commits talking about ATA disks via CAM (e.g. > SCSI emulation for ATA disks), but the only thing I'm aware of that > exists is SCSI emulation for ATAPI devices. > > > I've just tried "Modular ATA" configuration of Intel ICH7-based system > plus "device ahci" > > minus all traditional ata(4) kernel configuration, the kernel builds fine > > but boot messages do not show any attempt to detect my SATA HDD, > > so root mount just fails (I use GEOM UFS labels in my /etc/fstab). > > Typing ? at "mounroot" prompt I see only daX devices standing for my USB > cardreader > > and no device for HDD. > > This sounds like a different problem. You may want to talk to mav@ > about this. > > > It seems I miss ada(4) device and I cannot find it in 8.0 - not ada.ko > nor "device ada". > > Same. > To enable ahci, put ahci_load="YES" into loader.conf. Upon reboot, drives will be detected as adaX eg galacticdominator% dmesg |grep ada GEOM_STRIPE: Disk ada3 attached to stripe0. GEOM_STRIPE: Disk ada4 attached to stripe0. adam@galacticdominator.com:/usr/obj/usr/src/sys/GENERIC amd64 ada0 at ahcich0 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled ada1 at ahcich1 bus 0 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled ada2 at ahcich3 bus 0 target 0 lun 0 ada2: ATA/ATAPI-8 SATA 2.x device ada2: 300.000MB/s transfers ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Native Command Queueing enabled ada3 at ahcich4 bus 0 target 0 lun 0 ada3: ATA/ATAPI-8 SATA 2.x device ada3: 300.000MB/s transfers ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3: Native Command Queueing enabled ada4 at ahcich5 bus 0 target 0 lun 0 ada4: ATA/ATAPI-8 SATA 2.x device ada4: 300.000MB/s transfers ada4: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) ada4: Native Command Queueing enabled BIOS must be set to ahci controller mode, and obviously both disk and controller must support it. This works fine off a GENERIC. -- Adam Vande More From amvandemore at gmail.com Thu Nov 19 06:13:15 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Thu Nov 19 06:13:21 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <6201873e0911182211o17368cc4p2b4cfc0d702cb203@mail.gmail.com> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> <4B04B908.1020505@rdtc.ru> <20091119055025.GA30911@icarus.home.lan> <6201873e0911182211o17368cc4p2b4cfc0d702cb203@mail.gmail.com> Message-ID: <6201873e0911182213k384960e2tcc6acb592e9d78a7@mail.gmail.com> > > To enable ahci, put ahci_load="YES" into loader.conf. Upon reboot, drives > will be detected as adaX eg > > galacticdominator% dmesg |grep ada > GEOM_STRIPE: Disk ada3 attached to stripe0. > GEOM_STRIPE: Disk ada4 attached to stripe0. > adam@galacticdominator.com:/usr/obj/usr/src/sys/GENERIC amd64 > ada0 at ahcich0 bus 0 target 0 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > > ada0: 300.000MB/s transfers > ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing enabled > ada1 at ahcich1 bus 0 target 0 lun 0 > ada1: ATA/ATAPI-8 SATA 2.x device > > ada1: 300.000MB/s transfers > ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada1: Native Command Queueing enabled > ada2 at ahcich3 bus 0 target 0 lun 0 > ada2: ATA/ATAPI-8 SATA 2.x device > > ada2: 300.000MB/s transfers > ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada2: Native Command Queueing enabled > ada3 at ahcich4 bus 0 target 0 lun 0 > ada3: ATA/ATAPI-8 SATA 2.x device > ada3: 300.000MB/s transfers > ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada3: Native Command Queueing enabled > ada4 at ahcich5 bus 0 target 0 lun 0 > ada4: ATA/ATAPI-8 SATA 2.x device > ada4: 300.000MB/s transfers > ada4: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada4: Native Command Queueing enabled > > BIOS must be set to ahci controller mode, and obviously both disk and > controller must support it. This works fine off a GENERIC. > > Also note this can change loader mappings, so be sure to edit fstab if necessary. -- Adam Vande More From freebsd at jdc.parodius.com Thu Nov 19 06:27:56 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 19 06:28:04 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <6201873e0911182211o17368cc4p2b4cfc0d702cb203@mail.gmail.com> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> <4B04B908.1020505@rdtc.ru> <20091119055025.GA30911@icarus.home.lan> <6201873e0911182211o17368cc4p2b4cfc0d702cb203@mail.gmail.com> Message-ID: <20091119062754.GA32451@icarus.home.lan> On Thu, Nov 19, 2009 at 12:11:26AM -0600, Adam Vande More wrote: > > > > I don't know. I'm waiting for someone to actually write documentation > > on this. I keep seeing commits talking about ATA disks via CAM (e.g. > > SCSI emulation for ATA disks), but the only thing I'm aware of that > > exists is SCSI emulation for ATAPI devices. > > > > > I've just tried "Modular ATA" configuration of Intel ICH7-based system > > plus "device ahci" > > > minus all traditional ata(4) kernel configuration, the kernel builds fine > > > but boot messages do not show any attempt to detect my SATA HDD, > > > so root mount just fails (I use GEOM UFS labels in my /etc/fstab). > > > Typing ? at "mounroot" prompt I see only daX devices standing for my USB > > cardreader > > > and no device for HDD. > > > > This sounds like a different problem. You may want to talk to mav@ > > about this. > > > > > It seems I miss ada(4) device and I cannot find it in 8.0 - not ada.ko > > nor "device ada". > > > > Same. > > > > To enable ahci, put ahci_load="YES" into loader.conf. Upon reboot, drives > will be detected as adaX eg > > galacticdominator% dmesg |grep ada > GEOM_STRIPE: Disk ada3 attached to stripe0. > GEOM_STRIPE: Disk ada4 attached to stripe0. > adam@galacticdominator.com:/usr/obj/usr/src/sys/GENERIC amd64 > ada0 at ahcich0 bus 0 target 0 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing enabled > ada1 at ahcich1 bus 0 target 0 lun 0 > ada1: ATA/ATAPI-8 SATA 2.x device > ada1: 300.000MB/s transfers > ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada1: Native Command Queueing enabled > ada2 at ahcich3 bus 0 target 0 lun 0 > ada2: ATA/ATAPI-8 SATA 2.x device > ada2: 300.000MB/s transfers > ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada2: Native Command Queueing enabled > ada3 at ahcich4 bus 0 target 0 lun 0 > ada3: ATA/ATAPI-8 SATA 2.x device > ada3: 300.000MB/s transfers > ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada3: Native Command Queueing enabled > ada4 at ahcich5 bus 0 target 0 lun 0 > ada4: ATA/ATAPI-8 SATA 2.x device > ada4: 300.000MB/s transfers > ada4: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) > ada4: Native Command Queueing enabled > > BIOS must be set to ahci controller mode, and obviously both disk and > controller must support it. This works fine off a GENERIC. AHCI in the BIOS is enabled, AHCI in FreeBSD is in use. Kernel configuration is below my .sig, ditto with dmesg. World sources are from ~45 minutes prior to kernel build date (2009/11/17 20:07 PST). FreeBSD icarus.home.lan 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Tue Nov 17 20:07:21 PST 2009 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Like I said, this whole thing needs to get documented. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | # # Kernel configuration for the following system: # # OS: RELENG_8 # MB: Supermicro X7SBA # arch: amd64 # cpu HAMMER ident GENERIC makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # Debugging options options BREAK_TO_DEBUGGER # Sending a serial BREAK drops to DDB options KDB # Enable kernel debugger support options KDB_TRACE # Print stack trace automatically on panic options DDB # Support DDB options GDB # Support remote GDB # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices # NOTE: "device ata" is missing because we use the Modular ATA core # to only include the ATA-related drivers we need (e.g. AHCI). device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # Modular ATA device atacore # Core ATA functionality device ataisa # ISA bus support device atapci # PCI bus support; only generic chipset support device ataahci # AHCI SATA device ataintel # Intel # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Serial (COM) ports device uart # Generic UART driver # PCI Ethernet NICs. device em # Intel PRO/1000 Gigabit Ethernet Family # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # Intel Core/Core2Duo CPU temperature monitoring driver device coretemp # SMBus support, needed for bsdhwmon device smbus device smb device ichsmb # pf ALTQ support options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Detection options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing options ALTQ_NOPCC # Required for SMP build Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-PRERELEASE #0: Tue Nov 17 20:07:21 PST 2009 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4112576512 (3922 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xdc000000-0xdc0003ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib3: irq 16 at device 28.0 on pci0 pci5: on pcib3 pcib4: irq 16 at device 28.4 on pci0 pci13: on pcib4 em0: port 0x2000-0x201f mem 0xdc200000-0xdc21ffff irq 16 at device 0.0 on pci13 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:d2:22:d0 pcib5: irq 17 at device 28.5 on pci0 pci15: on pcib5 em1: port 0x3000-0x301f mem 0xdc300000-0xdc31ffff irq 17 at device 0.0 on pci15 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:d2:22:d1 uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x18a0-0x18bf irq 22 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] usbus6: on uhci5 ehci1: mem 0xdc000400-0xdc0007ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pci17: on pcib6 vgapci0: port 0x4000-0x407f mem 0xde000000-0xdfffffff,0xdc400000-0xdc43ffff at device 4.0 on pci17 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x18e0-0x18ff mem 0xdc000800-0xdc000fff irq 17 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ichsmb0: port 0x1100-0x111f mem 0xdc001000-0xdc0010ff irq 17 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ad8: 190782MB at ata4-master SATA150 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ad10: 953869MB at ata5-master SATA300 ad14: 953869MB at ata7-master SATA300 SMP: AP CPU #1 Launched! uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ad8s1a ZFS filesystem version 13 ZFS storage pool version 13 em0: link state changed to UP From mav at FreeBSD.org Thu Nov 19 08:22:58 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Nov 19 08:23:06 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B04B908.1020505@rdtc.ru> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> <4B04B908.1020505@rdtc.ru> Message-ID: <4B05005D.9040706@FreeBSD.org> Eugene Grosbein wrote: > Jeremy Chadwick wrote: >> I didn't have this problem. System has AHCI in use, and the kernel is >> built to make use of modular atacore. Specifically: >> >> # Modular ATA >> device atacore # Core ATA functionality >> device ataisa # ISA bus support >> device atapci # PCI bus support; only generic chipset support >> device ataahci # AHCI SATA >> device ataintel # Intel > > How should STABLE user (not tracking freebsd-current@) learn about CAM ATA configuration? > There is ahci(4) manual page in 8.0-PRERELEASE but no ada(4) that is linked here. > > I've just tried "Modular ATA" configuration of Intel ICH7-based system plus "device ahci" > minus all traditional ata(4) kernel configuration, the kernel builds fine > but boot messages do not show any attempt to detect my SATA HDD, > so root mount just fails (I use GEOM UFS labels in my /etc/fstab). > Typing ? at "mounroot" prompt I see only daX devices standing for my USB cardreader > and no device for HDD. Read ahci(4) carefully. It has all possible references. If you think it is not enough, propose patches. > It seems I miss ada(4) device and I cannot find it in 8.0 - not ada.ko nor "device ada". ada, same as da goes as part of cam module. It is not possible to load them separately now. But for kernel configuration it is separate option. -- Alexander Motin From gerrit at pmp.uni-hannover.de Thu Nov 19 08:37:53 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Nov 19 08:38:00 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <4B0430BF.4010201@barryp.org> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> <4B0430BF.4010201@barryp.org> Message-ID: <20091119093707.34999054.gerrit@pmp.uni-hannover.de> On Wed, 18 Nov 2009 11:37:03 -0600 Barry Pederson wrote about Re: Support for SAS/SATA non-RAID adapters: > > I guess the version of the card I have here was actually intended to > > be used in some kind of special Supermirco-Extension Slot. However, > > it fits into a standard PCIe slot and works nicely there as far as I > > can tell. Do you have the opportunity of using a riser card that > > would give you one more slot? BP> Those Supermicro UIO cards look like backwards PCIe cards. Do they BP> come with other brackets for fitting into a PCIe slot, or did you have BP> to go bracketless? They only come with a bracket that does not exactly fit into a standard slot. Maybe the other bracket is available, but I did not care much about it and simply went for bracketless (not much of a problem with a low profile card). BP> didn't mention anything about brackets or how it'd work in PCIe slots. For me it simply works. Only the bracket does not fit. cu Gerrit From gerrit at pmp.uni-hannover.de Thu Nov 19 08:41:33 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?UTF-8?B?S8O8aG4=?=) Date: Thu Nov 19 08:41:45 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> Message-ID: <20091119094129.c74f805f.gerrit@pmp.uni-hannover.de> On Wed, 18 Nov 2009 09:35:56 -0800 Freddie Cash wrote about Re: Support for SAS/SATA non-RAID adapters: FC> > Hm, I don't know the recent exchange rate, but are you sure this is FC> > the same card? I paid something like 80,-? (excl. VAT). FC> Oops, you're right, was reading the model numbers wrong. The FC> LSI1068-based one is only $129 CDN, the Intel IOP-based ones are FC> $200-300 CDN. That makes sense then. FC> Last time I checked the Euro was in the $1.50-2.00 CDN range. Seems to be something like 1.55 these days. FC> > I guess the version of the card I have here was actually intended to FC> > be used in some kind of special Supermirco-Extension Slot. However, FC> > it fits into a standard PCIe slot and works nicely there as far as I FC> > can tell. Do you have the opportunity of using a riser card that FC> > would give you one more slot? FC> Urgh, I have yet to find a riser card that will plug into a Tyan FC> motherboard and not cause issues. Due to all the issues we've had FC> with riser cards in the past, we have sworn off all riser cards. For FC> our 2U servers, we use low-profile cards to avoid risers. I had some trouble with risers in the past, too. However, I have a Tyan Transport here that seems to work nicely at least with the riser that came with the system. FC> I'll keep looking for a PCI-X card. These look like they'll cover our FC> PCIe needs. Please let us know if you find one that is suitable. I spent quite some time to dig out the Supermicro card; cheap (without raid) and FreeBSD-supported cards with more than 4 channels are not that common. cu Gerrit From gerrit at pmp.uni-hannover.de Thu Nov 19 08:52:47 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Nov 19 08:52:54 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <4B0447EF.1080703@barryp.org> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> <4B0430BF.4010201@barryp.org> <20091118180027.GA16477@icarus.home.lan> <20091118181008.GA16741@icarus.home.lan> <4B0447EF.1080703@barryp.org> Message-ID: <20091119095240.4ece2490.gerrit@pmp.uni-hannover.de> On Wed, 18 Nov 2009 13:15:59 -0600 Barry Pederson wrote about Re: Support for SAS/SATA non-RAID adapters: BP> What I was questioning was where the OP said: "it fits into a standard BP> PCIe slot and works nicely there as far as I can tell" - which to me BP> sounds like you could use this HBA in a *NON-Supermicro* motherboard. BP> I was just wondering if that was truly the case, given how in the BP> photos it looks to be arranged physically backwards from a regular BP> PCIe card, and given how you mention "The UIO slot itself is BP> proprietary". I'm sorry if my comment "fits into a standard PCIe slot" was misleading here. I wanted to state that -although Supermirco lists this one as a card for UIO- I plugged it into a standard PCIe slot and it simply works there for me. Just the mounting bracket it came with did not fit, but for a low profile card it is not that difficult to live without it. BP> But some more digging on Google has turned up a few mentions along the BP> lines of: BP> BP> """ BP> This card plugs into a normal PCIe 8x slot but the BP> metal mounting bracket bolted to the card is made BP> for a UIO slot (which is why it's so cheap). BP> BP> All you have to do is remove the metal bracket and BP> zip-tie the card to your case for mechanical support. BP> Electrically it'll work fine in a PCIe x8 or x16 slot. BP> """ That's exactly my experience. BP> If someone wanted to make PCIe compatible brackets for this affordable BP> card, they'd probably sell a fair number to small shops or home users. Yeah, I would also buy some. :-) cu Gerrit From freebsd at jdc.parodius.com Thu Nov 19 08:53:27 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 19 08:53:34 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B05005D.9040706@FreeBSD.org> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> <4B04B908.1020505@rdtc.ru> <4B05005D.9040706@FreeBSD.org> Message-ID: <20091119085325.GA35228@icarus.home.lan> On Thu, Nov 19, 2009 at 10:22:53AM +0200, Alexander Motin wrote: > Eugene Grosbein wrote: > > Jeremy Chadwick wrote: > >> I didn't have this problem. System has AHCI in use, and the kernel is > >> built to make use of modular atacore. Specifically: > >> > >> # Modular ATA > >> device atacore # Core ATA functionality > >> device ataisa # ISA bus support > >> device atapci # PCI bus support; only generic chipset support > >> device ataahci # AHCI SATA > >> device ataintel # Intel > > > > How should STABLE user (not tracking freebsd-current@) learn about CAM ATA configuration? > > There is ahci(4) manual page in 8.0-PRERELEASE but no ada(4) that is linked here. > > > > I've just tried "Modular ATA" configuration of Intel ICH7-based system plus "device ahci" > > minus all traditional ata(4) kernel configuration, the kernel builds fine > > but boot messages do not show any attempt to detect my SATA HDD, > > so root mount just fails (I use GEOM UFS labels in my /etc/fstab). > > Typing ? at "mounroot" prompt I see only daX devices standing for my USB cardreader > > and no device for HDD. > > Read ahci(4) carefully. It has all possible references. If you think it > is not enough, propose patches. I had no idea said details were in the ahci(4) man page, and I doubt the rest of the user community will know that either. There's also no man page for ada(4). There is some ambiguity in this part of the ahci(4) man page: AHCI hardware is also supported by ataahci driver from ata(4) subsystem. If both drivers are loaded at the same time, this one will be given precedence as the more functional of the two. The grammar here is very difficult to understand; "if both drivers" is too vague. The way this paragraph can be interpreted: - "If both drivers" could refer to ata(4) and ataahci - "If both drivers" could refer to ata(4) and ahci(4) - "If both drivers" could refer to ada(4) and ahci(4) - "If both drivers" could refer to ahci(4) and ata(4) I'll happily re-write the documentation for this if someone can take the time to explain what the paragraph actually is trying to say. Users are going to be very, very confused if there is a driver called ataahci and another driver called ahci. Finally, appropriate details need to be placed into the i386 and amd64 kernel configuration files; either in GENERIC (commented out) or in /sys/conf/NOTES. As it stands, there's nothing that informs anyone of this change, and if users are being pointed to the ahci(4) man page, they're going to get confused (see above). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From marius at nuenneri.ch Thu Nov 19 10:59:01 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Nov 19 10:59:08 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200911191123.08870.doconnor@gsoft.com.au> References: <493EE416-62CE-4EA4-81A7-8F802789D5DD@lassitu.de> <4AFF40B1.3040705@gsoft.com.au> <200911191123.08870.doconnor@gsoft.com.au> Message-ID: On Thu, Nov 19, 2009 at 01:53, Daniel O'Connor wrote: > On Sun, 15 Nov 2009, Daniel O'Connor wrote: >> ?> There's no need to detach anything. >> >> I'll try it when I get home and see how it goes. > > Unfortunately I get.. > > [midget 11:20] ~ >sudo zpool replace tank ad4p2 gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > cannot use '/dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc': must be a GEOM provider or regular file > [midget 11:20] ~ >ll /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > crw-r----- ?1 root ?operator ? ?0, 164 Oct 21 15:34 /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > Have you tried naming the GPT partitions and using /dev/gpt/* ? From randy at psg.com Thu Nov 19 11:08:58 2009 From: randy at psg.com (Randy Bush) Date: Thu Nov 19 11:09:05 2009 Subject: boot issues In-Reply-To: <200911180941.01049.jhb@freebsd.org> References: <200911180941.01049.jhb@freebsd.org> Message-ID: >> i386, 7.2-stable from last summer >> >> cvsupped releng_7 >> made and installed kernel >> buildworld >> boot -s >> installworld >> mergemaster >> reboot >> >> hung after beastie, just as it did the other month >> >> booted -s >> mount -2 / >> /etc/rc.d/hostid start >> /etc/rc.d/zfs start >> looked around and all seemed ok >> ^D >> came up ok >> >> and that is how it is running now >> >> but why will it boot through -s and not from beastie? > > Err, so what happens if you break into the boot loader prompt (option 6 IIRC) > and then just type 'boot', how far does it get before it hangs? subsequent testing (waited for low time for users) show it boots just fine. i can not explain the anomaly. randy From mav at FreeBSD.org Thu Nov 19 11:20:26 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Nov 19 11:20:33 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <1258622583.00185070.1258612202@10.7.7.3> References: <1258514582.00184609.1258501202@10.7.7.3> <1258536184.00184683.1258524603@10.7.7.3> <1258536184.00184684.1258525203@10.7.7.3> <1258611785.00185054.1258600801@10.7.7.3> <1258622581.00185063.1258610404@10.7.7.3> <1258622583.00185068.1258611604@10.7.7.3> <1258622583.00185070.1258612202@10.7.7.3> Message-ID: <4B0529EF.3080704@FreeBSD.org> Jeremy Chadwick wrote: > AHCI in the BIOS is enabled, AHCI in FreeBSD is in use. > > Kernel configuration is below my .sig, ditto with dmesg. World sources > are from ~45 minutes prior to kernel build date (2009/11/17 20:07 PST). > > FreeBSD icarus.home.lan 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Tue Nov 17 20:07:21 PST 2009 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 > > Like I said, this whole thing needs to get documented. FreeBSD now has two AHCI drivers - legacy ataahci from ata(4) infrastructure and new ahci(4) from CAM. According to atapci0: ... you are using legacy one. New one reports as ahci0: ... -- Alexander Motin From mav at FreeBSD.org Thu Nov 19 12:32:02 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Nov 19 12:32:09 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <1258633382.00185098.1258621201@10.7.7.3> References: <1258514582.00184609.1258501202@10.7.7.3> <1258536184.00184683.1258524603@10.7.7.3> <1258536184.00184684.1258525203@10.7.7.3> <1258611785.00185054.1258600801@10.7.7.3> <1258629784.00185092.1258619402@10.7.7.3> <1258633382.00185098.1258621201@10.7.7.3> Message-ID: <4B053ABD.5050705@FreeBSD.org> Jeremy Chadwick wrote: > On Thu, Nov 19, 2009 at 10:22:53AM +0200, Alexander Motin wrote: >> Read ahci(4) carefully. It has all possible references. If you think it >> is not enough, propose patches. > > I had no idea said details were in the ahci(4) man page, and I doubt the > rest of the user community will know that either. There's also no man > page for ada(4). > > There is some ambiguity in this part of the ahci(4) man page: > > AHCI hardware is also supported by ataahci driver from ata(4) subsystem. > If both drivers are loaded at the same time, this one will be given > precedence as the more functional of the two. > > The grammar here is very difficult to understand; "if both drivers" is > too vague. The way this paragraph can be interpreted: > > - "If both drivers" could refer to ata(4) and ataahci No. ataahci is a part of ata(4). > - "If both drivers" could refer to ata(4) and ahci(4) Yes, if with ata(4) understand it's ataahci part. > - "If both drivers" could refer to ada(4) and ahci(4) No. It is mentioned in ahci(4), that ada is peripheral driver. Not a controller. > - "If both drivers" could refer to ahci(4) and ata(4) It is same as second. > I'll happily re-write the documentation for this if someone can take the > time to explain what the paragraph actually is trying to say. Welcome. > Users are > going to be very, very confused if there is a driver called ataahci and > another driver called ahci. This is temporal situation, until new infrastructure will settle. Then old one will be removed. > Finally, appropriate details need to be placed into the i386 and amd64 > kernel configuration files; either in GENERIC (commented out) or in > /sys/conf/NOTES. As it stands, there's nothing that informs anyone of > this change, and if users are being pointed to the ahci(4) man page, > they're going to get confused (see above). Both new ahci and siis drivers are mentioned in NOTES file. -- Alexander Motin From doconnor at gsoft.com.au Thu Nov 19 12:35:44 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Nov 19 12:35:52 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: <200911191123.08870.doconnor@gsoft.com.au> Message-ID: <200911192305.35337.doconnor@gsoft.com.au> On Thu, 19 Nov 2009, Marius N?nnerich wrote: > > ?operator ? ?0, 164 Oct 21 15:34 > > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > > Have you tried naming the GPT partitions and using /dev/gpt/* ? Nope, how would I do that? I'd be surprised if it worked TBH.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091119/34b2b177/attachment.pgp From tevans.uk at googlemail.com Thu Nov 19 12:45:07 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Thu Nov 19 12:45:15 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200911192305.35337.doconnor@gsoft.com.au> References: <200911191123.08870.doconnor@gsoft.com.au> <200911192305.35337.doconnor@gsoft.com.au> Message-ID: <2e027be00911190444s1ce5f297o9064bb9c0d28ef30@mail.gmail.com> On Thu, Nov 19, 2009 at 12:35 PM, Daniel O'Connor wrote: > On Thu, 19 Nov 2009, Marius N?nnerich wrote: > > > operator 0, 164 Oct 21 15:34 > > > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > > > > Have you tried naming the GPT partitions and using /dev/gpt/* ? > > Nope, how would I do that? > > I'd be surprised if it worked TBH.. > > Use the -l flag to gpart when creating the partitions. I'm not sure if there is a way to label them after the fact. I found it led to a much more descriptive/reliable pool, as I can plug the disks in anywhere and get the same results: pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/samsung15-1 ONLINE 0 0 0 gpt/samsung15-2 ONLINE 0 0 0 gpt/samsung15-3 ONLINE 0 0 0 gpt/samsung15-4 ONLINE 0 0 0 gpt/seagate15-1 ONLINE 0 0 0 gpt/seagate15-2 ONLINE 0 0 0 I use the geom name 'gpt/foo' when referring to the disks in zpool. All works perfectly. Cheers Tom From marius at nuenneri.ch Thu Nov 19 12:49:34 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Nov 19 12:49:43 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <2e027be00911190444s1ce5f297o9064bb9c0d28ef30@mail.gmail.com> References: <200911191123.08870.doconnor@gsoft.com.au> <200911192305.35337.doconnor@gsoft.com.au> <2e027be00911190444s1ce5f297o9064bb9c0d28ef30@mail.gmail.com> Message-ID: On Thu, Nov 19, 2009 at 13:44, Tom Evans wrote: > On Thu, Nov 19, 2009 at 12:35 PM, Daniel O'Connor > wrote: >> >> On Thu, 19 Nov 2009, Marius N?nnerich wrote: >> > > ?operator ? ?0, 164 Oct 21 15:34 >> > > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc >> > >> > Have you tried naming the GPT partitions and using /dev/gpt/* ? >> >> Nope, how would I do that? >> >> I'd be surprised if it worked TBH.. >> > > Use the -l flag to gpart when creating the partitions. I'm not sure if there > is a way to label them after the fact. I found it led to a much more > descriptive/reliable pool, as I can plug the disks in anywhere and get the > same results: > > ? pool: tank > ?state: ONLINE > ?scrub: none requested > config: > > ??? NAME????????????????? STATE???? READ WRITE CKSUM > ??? tank????????????????? ONLINE?????? 0???? 0???? 0 > ??? ? raidz1????????????? ONLINE?????? 0???? 0???? 0 > ??? ??? gpt/samsung15-1?? ONLINE?????? 0???? 0???? 0 > ??? ??? gpt/samsung15-2?? ONLINE?????? 0???? 0???? 0 > ??? ??? gpt/samsung15-3?? ONLINE?????? 0???? 0???? 0 > ??? ??? gpt/samsung15-4?? ONLINE?????? 0???? 0???? 0 > ??? ??? gpt/seagate15-1 ? ONLINE?????? 0???? 0???? 0 > ??? ??? gpt/seagate15-2?? ONLINE?????? 0???? 0???? 0 > > I use the geom name 'gpt/foo' when referring to the disks in zpool. All > works perfectly. > I never tried it but maybe gpart modify -l works too. From avg at icyb.net.ua Thu Nov 19 13:27:27 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Nov 19 13:27:35 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B05005D.9040706@FreeBSD.org> References: <4B03322A.2080608@FreeBSD.org> <4B038E75.1010501@rdtc.ru> <20091118061726.GA1675@icarus.home.lan> <4B04B908.1020505@rdtc.ru> <4B05005D.9040706@FreeBSD.org> Message-ID: <4B0547BB.5050802@icyb.net.ua> on 19/11/2009 10:22 Alexander Motin said the following: > Eugene Grosbein wrote: >> Jeremy Chadwick wrote: >>> I didn't have this problem. System has AHCI in use, and the kernel is >>> built to make use of modular atacore. Specifically: >>> >>> # Modular ATA >>> device atacore # Core ATA functionality >>> device ataisa # ISA bus support >>> device atapci # PCI bus support; only generic chipset support >>> device ataahci # AHCI SATA >>> device ataintel # Intel >> How should STABLE user (not tracking freebsd-current@) learn about CAM ATA configuration? >> There is ahci(4) manual page in 8.0-PRERELEASE but no ada(4) that is linked here. [snip] > Read ahci(4) carefully. It has all possible references. If you think it > is not enough, propose patches. > >> It seems I miss ada(4) device and I cannot find it in 8.0 - not ada.ko nor "device ada". > > ada, same as da goes as part of cam module. It is not possible to load > them separately now. But for kernel configuration it is separate option. I think that part of what Euegene is said and what is confusing is that ahci.4 manual page has a cross-reference to ada.4, but the latter doesn't exist. Neither as a distinct manual page nor as a link. -- Andriy Gapon From karl at denninger.net Thu Nov 19 13:54:54 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Nov 19 13:55:02 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! Message-ID: <4B054DCC.6020701@denninger.net> It appears that V8.x has changed some device names in the serial subsystem, moving them to the "puc" naming (e.g. ttydxx moves to ttyuxx) There is a fairly serious issue with Hylafax under the new setup that I have not (yet) been able to run down. It manifests as ports that simply stop working, where they were fine under 7.x, after some indeterminate period of time. I will update as I have more information - this is a serious issue for anyone who needs working serial ports on multiport cards under FreeBSD for things like a fax server..... this is not the sort of "surprise" one wants to see! -- Karl Denninger From mike at sentex.net Thu Nov 19 13:57:41 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 19 13:57:48 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <4B054DCC.6020701@denninger.net> References: <4B054DCC.6020701@denninger.net> Message-ID: <200911191357.nAJDvd3X095748@lava.sentex.ca> At 08:53 AM 11/19/2009, Karl Denninger wrote: >I will update as I have more information - this is a serious issue for >anyone who needs working serial ports on multiport cards under FreeBSD >for things like a fax server..... this is not the sort of "surprise" one >wants to see! Its not the puc per se as the transition from sio to uart from /usr/src/UPDATING 20080713: The sio(4) driver has been removed from the i386 and amd64 kernel configuration files. This means uart(4) is now the default serial port driver on those platforms as well. To prevent collisions with the sio(4) driver, the uart(4) driver uses different names for its device nodes. This means the onboard serial port will now most likely be called "ttyu0" instead of "ttyd0". You may need to reconfigure applications to use the new device names. When using the serial port as a boot console, be sure to update /boot/device.hints and /etc/ttys before booting the new kernel. If you forget to do so, you can still manually specify the hints at the loader prompt: set hint.uart.0.at="isa" set hint.uart.0.port="0x3F8" set hint.uart.0.flags="0x10" set hint.uart.0.irq="4" boot -s >-- Karl Denninger > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From karl at denninger.net Thu Nov 19 14:01:49 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Nov 19 14:01:59 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <200911191357.nAJDvd3X095748@lava.sentex.ca> References: <4B054DCC.6020701@denninger.net> <200911191357.nAJDvd3X095748@lava.sentex.ca> Message-ID: <4B054F6D.70300@denninger.net> Mike Tancsa wrote: > At 08:53 AM 11/19/2009, Karl Denninger wrote: > >> I will update as I have more information - this is a serious issue for >> anyone who needs working serial ports on multiport cards under FreeBSD >> for things like a fax server..... this is not the sort of "surprise" one >> wants to see! > > Its not the puc per se as the transition from sio to uart > > from /usr/src/UPDATING > > 20080713: > The sio(4) driver has been removed from the i386 and amd64 > kernel configuration files. This means uart(4) is now the > default serial port driver on those platforms as well. > > To prevent collisions with the sio(4) driver, the uart(4) driver > uses different names for its device nodes. This means the > onboard serial port will now most likely be called "ttyu0" > instead of "ttyd0". You may need to reconfigure applications to > use the new device names. > > When using the serial port as a boot console, be sure to update > /boot/device.hints and /etc/ttys before booting the new kernel. > If you forget to do so, you can still manually specify the hints > at the loader prompt: > > set hint.uart.0.at="isa" > set hint.uart.0.port="0x3F8" > set hint.uart.0.flags="0x10" > set hint.uart.0.irq="4" > boot -s Well ok then the uart driver is BROKEN. It simply locks up on the port after some period of time, returning nothing. I have found no way to reset the port other than a reboot either. That's a "surprise" that people running fax servers and other similar things are going to be very unhappy about. -- Karl From mike at sentex.net Thu Nov 19 14:04:19 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 19 14:04:26 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <4B054F6D.70300@denninger.net> References: <4B054DCC.6020701@denninger.net> <200911191357.nAJDvd3X095748@lava.sentex.ca> <4B054F6D.70300@denninger.net> Message-ID: <200911191404.nAJE4HEm095790@lava.sentex.ca> At 09:00 AM 11/19/2009, Karl Denninger wrote: >Well ok then the uart driver is BROKEN. > >It simply locks up on the port after some period of time, returning >nothing. I have found no way to reset the port other than a reboot >either. That's a "surprise" that people running fax servers and other >similar things are going to be very unhappy about. Which serial card are you using ? I have a number of PCI cards (lava for example) that are working quite well with the puc and uart driver combo. Perhaps you could post some details about the hardware used thats having issues. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From karl at denninger.net Thu Nov 19 14:15:46 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Nov 19 14:15:53 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! Message-ID: <4B0552B2.2020000@denninger.net> Mike Tancsa wrote: > At 09:00 AM 11/19/2009, Karl Denninger wrote: >> Well ok then the uart driver is BROKEN. >> >> It simply locks up on the port after some period of time, returning >> nothing. I have found no way to reset the port other than a reboot >> either. That's a "surprise" that people running fax servers and other >> similar things are going to be very unhappy about. > > Which serial card are you using ? I have a number of PCI cards (lava > for example) that are working quite well with the puc and uart driver > combo. Perhaps you could post some details about the hardware used > thats having issues. > > ---Mike puc0: port 0x4060-0x407f,0x4040-0x405f mem 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 puc0: [FILTER] uart2: <16550 or compatible> on puc0 uart2: [FILTER] uart3: <16550 or compatible> on puc0 uart3: [FILTER] uart4: <16550 or compatible> on puc0 uart4: [FILTER] uart5: <16550 or compatible> on puc0 uart5: [FILTER] It's a generic board with four ports sitting on the PCI bus. Nothing special, no smarts, just four 16550 uarts. Port "0" is on the motherboard and I am using that to talk to my NMEA clock (using PPS, which is working). I also am using one of the "troubled" ports to talk to an APC UPS, again, without problems. Trivial and reasonably-trivial applications work fine on the uart/puc combination. Hylafax requires correct modem control that is FLAWLESS or it WILL blow up. This is an area where smart cards have in the past run into driver trouble (going back years; I have lots of experience with driver issues on so-called "smart" cards going back more than a decade in this sort of application!) and now, it appears that sickness has translated into the UART driver as well. The system in question sends hundreds of faxes a day and any sort of squirrelly driver problems in the serial subsystem show up almost instantly (I updated to RC2 on that machine last night and it took less than an hour for the modems to wedge this morning.) I tried to flip back to sio() as the driver in GENERIC and it appears that can't be done, or I'm missing some interdependency somewhere (doing so throws all sorts of errors related to the include files) -- Karl From mike at sentex.net Thu Nov 19 14:27:30 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 19 14:27:37 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <4B0552B2.2020000@denninger.net> References: <4B0552B2.2020000@denninger.net> Message-ID: <200911191427.nAJERSl6095906@lava.sentex.ca> At 09:14 AM 11/19/2009, Karl Denninger wrote: >Mike Tancsa wrote: > > At 09:00 AM 11/19/2009, Karl Denninger wrote: > >> Well ok then the uart driver is BROKEN. > >> > >> It simply locks up on the port after some period of time, returning > >> nothing. I have found no way to reset the port other than a reboot > >> either. That's a "surprise" that people running fax servers and other > >> similar things are going to be very unhappy about. > > > > Which serial card are you using ? I have a number of PCI cards (lava > > for example) that are working quite well with the puc and uart driver > > combo. Perhaps you could post some details about the hardware used > > thats having issues. > > > > ---Mike >puc0: port >0x4060-0x407f,0x4040-0x405f mem >0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 >puc0: [FILTER] >uart2: <16550 or compatible> on puc0 >uart2: [FILTER] >uart3: <16550 or compatible> on puc0 >uart3: [FILTER] >uart4: <16550 or compatible> on puc0 >uart4: [FILTER] >uart5: <16550 or compatible> on puc0 >uart5: [FILTER] > >It's a generic board with four ports sitting on the PCI bus. Nothing If you serial app is low speed (e.g 9600), try adding hint.uart.2.flags="0x100" hint.uart.3.flags="0x100" hint.uart.4.flags="0x100" hint.uart.5.flags="0x100" to /boot/device.hints and reboot ---Mike >special, no smarts, just four 16550 uarts. Port "0" is on the >motherboard and I am using that to talk to my NMEA clock (using PPS, >which is working). I also am using one of the "troubled" ports to talk >to an APC UPS, again, without problems. > >Trivial and reasonably-trivial applications work fine on the uart/puc >combination. Hylafax requires correct modem control that is FLAWLESS or >it WILL blow up. This is an area where smart cards have in the past run >into driver trouble (going back years; I have lots of experience with >driver issues on so-called "smart" cards going back more than a decade >in this sort of application!) and now, it appears that sickness has >translated into the UART driver as well. > >The system in question sends hundreds of faxes a day and any sort of >squirrelly driver problems in the serial subsystem show up almost >instantly (I updated to RC2 on that machine last night and it took less >than an hour for the modems to wedge this morning.) > >I tried to flip back to sio() as the driver in GENERIC and it appears >that can't be done, or I'm missing some interdependency somewhere (doing >so throws all sorts of errors related to the include files) > >-- Karl > > > > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From karl at denninger.net Thu Nov 19 14:29:02 2009 From: karl at denninger.net (Karl Denninger) Date: Thu Nov 19 14:29:12 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <200911191427.nAJERSl6095906@lava.sentex.ca> References: <4B0552B2.2020000@denninger.net> <200911191427.nAJERSl6095906@lava.sentex.ca> Message-ID: <4B0555CD.8050704@denninger.net> Mike Tancsa wrote: > At 09:14 AM 11/19/2009, Karl Denninger wrote: > > >> Mike Tancsa wrote: >> > At 09:00 AM 11/19/2009, Karl Denninger wrote: >> >> Well ok then the uart driver is BROKEN. >> >> >> >> It simply locks up on the port after some period of time, returning >> >> nothing. I have found no way to reset the port other than a reboot >> >> either. That's a "surprise" that people running fax servers and >> other >> >> similar things are going to be very unhappy about. >> > >> > Which serial card are you using ? I have a number of PCI cards (lava >> > for example) that are working quite well with the puc and uart driver >> > combo. Perhaps you could post some details about the hardware used >> > thats having issues. >> > >> > ---Mike >> puc0: port >> 0x4060-0x407f,0x4040-0x405f mem >> 0x94503000-0x94503fff,0x94502000-0x94502fff irq 16 at device 0.0 on pci3 >> puc0: [FILTER] >> uart2: <16550 or compatible> on puc0 >> uart2: [FILTER] >> uart3: <16550 or compatible> on puc0 >> uart3: [FILTER] >> uart4: <16550 or compatible> on puc0 >> uart4: [FILTER] >> uart5: <16550 or compatible> on puc0 >> uart5: [FILTER] >> >> It's a generic board with four ports sitting on the PCI bus. Nothing > > > If you serial app is low speed (e.g 9600), try adding > > hint.uart.2.flags="0x100" > hint.uart.3.flags="0x100" > hint.uart.4.flags="0x100" > hint.uart.5.flags="0x100" > > to /boot/device.hints and reboot > > ---Mike It's not. What does that do? (The ports run 38400 or 57600 - higher preferred, 38.4k is the minimum for it to work) -- Karl From mike at sentex.net Thu Nov 19 14:33:54 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 19 14:34:01 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <4B0555CD.8050704@denninger.net> References: <4B0552B2.2020000@denninger.net> <200911191427.nAJERSl6095906@lava.sentex.ca> <4B0555CD.8050704@denninger.net> Message-ID: <200911191433.nAJEXqqT095949@lava.sentex.ca> At 09:27 AM 11/19/2009, Karl Denninger wrote: >It's not. > >What does that do? From the man page, With flags encoded as: 0x00010 device is potential system console 0x00080 use this port for remote kernel debugging 0x00100 set RX FIFO trigger level to ``low'' (NS8250 only) 0x00200 set RX FIFO trigger level to ``medium low'' (NS8250 only) 0x00400 set RX FIFO trigger level to ``medium high'' (default, NS8250 only) 0x00800 set RX FIFO trigger level to ``high'' (NS8250 only) You might still want to try adjusting how fast the FIFOs are flushed to see if thats your issue. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From jhb at freebsd.org Thu Nov 19 14:55:18 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 14:55:27 2009 Subject: RELENG_7: Kernel Compile Failure In-Reply-To: <8cd25834fbad3a9327a6dde9a7697deb.squirrel@webmail.lerctr.org> References: <175fd45439c7cf285eb894361ae58e5a.squirrel@webmail.lerctr.org> <20091115191039.GV1649@albert.catwhisker.org> <8cd25834fbad3a9327a6dde9a7697deb.squirrel@webmail.lerctr.org> Message-ID: <200911190934.10519.jhb@freebsd.org> On Sunday 15 November 2009 2:15:51 pm Larry Rosenman wrote: > > On Sun, November 15, 2009 1:10 pm, David Wolfskill wrote: > > On Sun, Nov 15, 2009 at 12:37:23PM -0600, Larry Rosenman wrote: > >> ... > >> /usr/src/sys/kern/kern_conf.c:698: error: 'struct cdevsw' has no member > >> named 'd_mmap2' > >> *** Error code 1 > >> > >> Stop in /usr/obj/usr/src/sys/THEBIGHONKER. > >> *** Error code 1 > >> > >> Stop in /usr/src. > >> *** Error code 1 > >> > >> Stop in /usr/src. > >> # > >> > >> > >> Ideas? > >> ... > > > > Try a different mirror, perhaps? I've had no problems tracking stable/7 > > daily (though I'm using SVN). > > Thanks. Pulled a update from cvsup5.us.freebsd.org, and changes were > picked up. > > Can someone check the health of cvsup17.us.freebsd.org? This should be resolved now I believe? -- John Baldwin From djv at iki.fi Thu Nov 19 14:59:26 2009 From: djv at iki.fi (Tuomo Latto) Date: Thu Nov 19 14:59:33 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <20091117163754.GA98592@icarus.home.lan> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> <4B02CCBA.4070909@t-online.hu> <20091117163754.GA98592@icarus.home.lan> Message-ID: <4B055AB7.50804@iki.fi> Jeremy Chadwick wrote: > On Tue, Nov 17, 2009 at 05:18:02PM +0100, Mikael Bak wrote: >> Matt Wilks wrote: >>> I'm attempting to install NSIS (http://nsis.sourceforge.net/) on an >>> amd64 FreeBSD 7.2 system and having trouble. When I run >>> >> [snip] >> >> >From the project's home page: >> "NSIS (Nullsoft Scriptable Install System) is a professional open source >> system to create Windows installers." >> >> Is this supposed to compile on unix-like systems? > > Yes it is. It's supposed to be compilable on any POSIX-compliant > system, without requiring WINE. With or without a cross-compiler? -- Tuomo ... [X] nail here for new monitor From vburke at skow.net Thu Nov 19 15:33:56 2009 From: vburke at skow.net (Vern Burke) Date: Thu Nov 19 15:34:03 2009 Subject: FreeBSD 7.2, NFS, and Xen Cloud Platform Message-ID: <4B0553F6.7010402@skow.net> Greetings all: I'm attempting to run my FreeBSD 7.2 server as an NFS backend for XCP. I can mount the share from any FreeBSD box, I can mount it from XCP's Linux command prompt, trying to mount it from XCP gives an error that the share couldn't be mounted because the server denied permission. I'm not seeing any messages in the FreeBSD log files, is there any way I can get the NFS server to give me more details so I can sort this? Vern -- Vern Burke SwiftWater Telecom http://www.swiftwatertel.com ISP/CLEC Engineering Services Data Center Services Remote Backup Services From bp at barryp.org Thu Nov 19 15:52:58 2009 From: bp at barryp.org (Barry Pederson) Date: Thu Nov 19 15:53:06 2009 Subject: Support for SAS/SATA non-RAID adapters In-Reply-To: <20091119095240.4ece2490.gerrit@pmp.uni-hannover.de> References: <20091118101706.780938ba.gerrit@pmp.uni-hannover.de> <20091118180939.2691c2cd.gerrit@pmp.uni-hannover.de> <4B0430BF.4010201@barryp.org> <20091118180027.GA16477@icarus.home.lan> <20091118181008.GA16741@icarus.home.lan> <4B0447EF.1080703@barryp.org> <20091119095240.4ece2490.gerrit@pmp.uni-hannover.de> Message-ID: <4B0569D6.9030502@barryp.org> Gerrit K?hn wrote: > On Wed, 18 Nov 2009 13:15:59 -0600 Barry Pederson wrote > BP> If someone wanted to make PCIe compatible brackets for this affordable > BP> card, they'd probably sell a fair number to small shops or home users. > > Yeah, I would also buy some. :-) > I was browsing this bracket mfg's page, I wonder if they might have something off-the-shelf that would be suitable http://www.purcellbrackets.com/dbblanks.asp Barry From david at catwhisker.org Thu Nov 19 16:03:42 2009 From: david at catwhisker.org (David Wolfskill) Date: Thu Nov 19 16:03:49 2009 Subject: RELENG_7: Kernel Compile Failure In-Reply-To: <200911190934.10519.jhb@freebsd.org> References: <175fd45439c7cf285eb894361ae58e5a.squirrel@webmail.lerctr.org> <20091115191039.GV1649@albert.catwhisker.org> <8cd25834fbad3a9327a6dde9a7697deb.squirrel@webmail.lerctr.org> <200911190934.10519.jhb@freebsd.org> Message-ID: <20091119155251.GM1637@albert.catwhisker.org> On Thu, Nov 19, 2009 at 09:34:10AM -0500, John Baldwin wrote: > ... > > > Try a different mirror, perhaps? I've had no problems tracking stable/7 > > > daily (though I'm using SVN). > > > > Thanks. Pulled a update from cvsup5.us.freebsd.org, and changes were > > picked up. > > > > Can someone check the health of cvsup17.us.freebsd.org? > > This should be resolved now I believe? I'm not really in a convenient position to check -- I normally use cvsup4 for the CVS stuff, and maintain a private SVN mirror for src. Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091119/f45b5860/attachment.pgp From mike at sentex.net Thu Nov 19 16:58:50 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 19 16:58:58 2009 Subject: bug with some em nics on RELENG_7 In-Reply-To: <2a41acea0911181629r4eb1a199we28a94a82ec67cf@mail.gmail.com > References: <200911182130.nAILUJCR089766@lava.sentex.ca> <2a41acea0911181629r4eb1a199we28a94a82ec67cf@mail.gmail.com> Message-ID: <200911191658.nAJGwnp0096685@lava.sentex.ca> At 07:29 PM 11/18/2009, Jack Vogel wrote: >Hey Mike, > >Can you check if you see the same behavior on RELENG 8? For RELENG_8. I installed an fxp card and netbooted off it. I assigned an IP address to the onboard nic (em5). Pinged itself, got a MAC and response. Plugged in the cable, pinged the other side, all ok Did the same, but pinged the other side, and plugged the cable in, all worked as expected. # ping 10.177.194.18 PING 10.177.194.18 (10.177.194.18): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down 64 bytes from 10.177.194.18: icmp_seq=30 ttl=64 time=1329.918 ms 64 bytes from 10.177.194.18: icmp_seq=31 ttl=64 time=324.925 ms 64 bytes from 10.177.194.18: icmp_seq=32 ttl=64 time=0.054 ms 64 bytes from 10.177.194.18: icmp_seq=33 ttl=64 time=0.055 ms 64 bytes from 10.177.194.18: icmp_seq=34 ttl=64 time=0.047 ms 64 bytes from 10.177.194.18: icmp_seq=35 ttl=64 time=0.050 ms 64 bytes from 10.177.194.18: icmp_seq=36 ttl=64 time=0.047 ms 64 bytes from 10.177.194.18: icmp_seq=37 ttl=64 time=0.049 ms 64 bytes from 10.177.194.18: icmp_seq=38 ttl=64 time=0.043 ms em4: port 0xcc00-0xcc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 em4: Using MSIX interrupts em4: [ITHREAD] em4: [ITHREAD] em4: [ITHREAD] em4: Ethernet address: 00:30:48:d6:ef:12 pcib7: irq 16 at device 28.1 on pci0 pci7: on pcib7 em5: port 0xdc00-0xdc1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 em5: Using MSIX interrupts em5: [ITHREAD] em5: [ITHREAD] em5: [ITHREAD] em5: Ethernet address: 00:30:48:d6:ef:13 So the problem is _not_ there under RELENG_8. I also tested the 2 PCIe nics to make sure they are still working, and they are. Full dmesg below opyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RC2 #0: Wed Nov 11 09:54:52 EST 2009 mdtancsa@ich10.sentex.ca:/usr/obj/usr/src/sys/alix i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2660.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 6446645248 (6148 MB) avail memory = 3137355776 (2992 MB) ACPI APIC Table: <011209 APIC2037> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: <011209 XSDT2037> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 em0: port 0xac00-0xac1f mem 0xface0000-0xfacfffff,0xfacc0000-0xfacdffff irq 16 at device 0.0 on pci1 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:78:e6:e0 em1: port 0xa880-0xa89f mem 0xfac80000-0xfac9ffff,0xfac60000-0xfac7ffff irq 17 at device 0.1 on pci1 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:78:e6:e1 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 5.0 on pci0 pci3: on pcib3 em2: port 0xbc00-0xbc1f mem 0xfade0000-0xfadfffff,0xfadc0000-0xfaddffff irq 16 at device 0.0 on pci3 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:15:17:cf:26:de em3: port 0xb880-0xb89f mem 0xfad80000-0xfad9ffff,0xfad60000-0xfad7ffff irq 17 at device 0.1 on pci3 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:15:17:cf:26:df pcib4: at device 7.0 on pci0 pci4: on pcib4 pcib5: at device 9.0 on pci0 pci5: on pcib5 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0x9c00-0x9c1f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0x9880-0x989f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0x9800-0x981f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfabde000-0xfabde3ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib6: irq 17 at device 28.0 on pci0 pci6: on pcib6 em4: port 0xcc00-0xcc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 em4: Using MSIX interrupts em4: [ITHREAD] em4: [ITHREAD] em4: [ITHREAD] em4: Ethernet address: 00:30:48:d6:ef:12 pcib7: irq 16 at device 28.1 on pci0 pci7: on pcib7 em5: port 0xdc00-0xdc1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 em5: Using MSIX interrupts em5: [ITHREAD] em5: [ITHREAD] em5: [ITHREAD] em5: Ethernet address: 00:30:48:d6:ef:13 uhci3: port 0x9480-0x949f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0x9400-0x941f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0x9080-0x909f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfabdc000-0xfabdc3ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib8: at device 30.0 on pci0 pci8: on pcib8 fxp0: port 0xec00-0xec3f mem 0xfbefe000-0xfbefefff,0xfbec0000-0xfbedffff irq 17 at device 1.0 on pci8 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:5d:ca:ce fxp0: [ITHREAD] vgapci0: mem 0xf9800000-0xf9ffffff,0xfbef8000-0xfbefbfff,0xfb000000-0xfb7fffff irq 17 at device 4.0 on pci8 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x9000-0x9007,0x8c00-0x8c03,0x8880-0x8887,0x8800-0x8803,0x8480-0x848f,0x8400-0x840f irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0x8000-0x8007,0x7c00-0x7c03,0x7880-0x7887,0x7800-0x7803,0x7480-0x748f,0x7400-0x740f irq 19 at device 31.5 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (38400,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] uart2: <16550 or compatible> port 0x3e8-0x3ef irq 5 on acpi0 uart2: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 8A, should be 87 20090521 tbutils-275 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! ugen1.1: at usbus1ugen0.1: at usbus0Root mount waiting for:ugen2.1: at usbus2 usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: on usbus0 ugen3.1: at usbus3uhub1: on usbus2 uhub2: on usbus1 uhub3: on usbus3 ugen4.1: at usbus4ugen5.1: at usbus5ugen7.1: at usbus7ugen6.1: at usbus6 uhub4: on usbus4 uhub5: on usbus5 uhub6: on usbus6 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from nfs:10.255.255.1:/home/pxe NFS ROOT: 10.255.255.1:/usr/home/pxe/ ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From tajudd at gmail.com Thu Nov 19 17:00:30 2009 From: tajudd at gmail.com (Tim Judd) Date: Thu Nov 19 17:00:37 2009 Subject: [solved] Re: Re: Re: diskless - NFS root mount problem In-Reply-To: <314774211.102489.1258609764004.JavaMail.apache@mail53.abv.bg> References: <314774211.102489.1258609764004.JavaMail.apache@mail53.abv.bg> Message-ID: On 11/18/09, Mario Pavlov wrote: > oh yes, I got what you meant now > true, I used /usr from the server because I wanted to have all my ports > available to the client. Is there a nice way to install ports only in the > diskless distribution ? > > thank you. > > Regards > Mario Just like any other port you install. you can either chroot into your diskless root filesystem (as I have it laid out, not you), and run the port tools. you can also run the package management tools. All programs are are files on the disk, there's no local registry as in windows to worry about. You can even compile on the diskless client. It just reads and writes files to the nfs server to compile ports. --TJ From jfvogel at gmail.com Thu Nov 19 17:27:39 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Nov 19 17:28:16 2009 Subject: bug with some em nics on RELENG_7 In-Reply-To: <200911191658.nAJGwnp0096685@lava.sentex.ca> References: <200911182130.nAILUJCR089766@lava.sentex.ca> <2a41acea0911181629r4eb1a199we28a94a82ec67cf@mail.gmail.com> <200911191658.nAJGwnp0096685@lava.sentex.ca> Message-ID: <2a41acea0911190927u1c90fa6cpe965f072a3339299@mail.gmail.com> Cool, so stable/7 will just need to be updated :) I need to catch up all the drivers in that stream actually. Thanks for testing!! Jack On Thu, Nov 19, 2009 at 8:58 AM, Mike Tancsa wrote: > At 07:29 PM 11/18/2009, Jack Vogel wrote: > >> Hey Mike, >> >> Can you check if you see the same behavior on RELENG 8? >> > > For RELENG_8. I installed an fxp card and netbooted off it. > > I assigned an IP address to the onboard nic (em5). Pinged itself, got a MAC > and response. Plugged in the cable, pinged the other side, all ok > > Did the same, but pinged the other side, and plugged the cable in, all > worked as expected. > # ping 10.177.194.18 > PING 10.177.194.18 (10.177.194.18): 56 data bytes > ping: sendto: Host is down > ping: sendto: Host is down > ping: sendto: Host is down > 64 bytes from 10.177.194.18: icmp_seq=30 ttl=64 time=1329.918 ms > 64 bytes from 10.177.194.18: icmp_seq=31 ttl=64 time=324.925 ms > 64 bytes from 10.177.194.18: icmp_seq=32 ttl=64 time=0.054 ms > 64 bytes from 10.177.194.18: icmp_seq=33 ttl=64 time=0.055 ms > 64 bytes from 10.177.194.18: icmp_seq=34 ttl=64 time=0.047 ms > 64 bytes from 10.177.194.18: icmp_seq=35 ttl=64 time=0.050 ms > 64 bytes from 10.177.194.18: icmp_seq=36 ttl=64 time=0.047 ms > 64 bytes from 10.177.194.18: icmp_seq=37 ttl=64 time=0.049 ms > 64 bytes from 10.177.194.18: icmp_seq=38 ttl=64 time=0.043 ms > > > em4: port 0xcc00-0xcc1f mem > 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 > > em4: Using MSIX interrupts > em4: [ITHREAD] > em4: [ITHREAD] > em4: [ITHREAD] > em4: Ethernet address: 00:30:48:d6:ef:12 > pcib7: irq 16 at device 28.1 on pci0 > pci7: on pcib7 > em5: port 0xdc00-0xdc1f mem > 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 > > em5: Using MSIX interrupts > em5: [ITHREAD] > em5: [ITHREAD] > em5: [ITHREAD] > em5: Ethernet address: 00:30:48:d6:ef:13 > > So the problem is _not_ there under RELENG_8. I also tested the 2 PCIe > nics to make sure they are still working, and they are. > > Full dmesg below > > opyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-RC2 #0: Wed Nov 11 09:54:52 EST 2009 > mdtancsa@ich10.sentex.ca:/usr/obj/usr/src/sys/alix i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2660.00-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 > > Features=0xbfebfbff > > Features2=0x98e3bd > AMD Features=0x28100000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 6446645248 (6148 MB) > avail memory = 3137355776 (2992 MB) > ACPI APIC Table: <011209 APIC2037> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 6 > ioapic0: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: <011209 XSDT2037> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bff00000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > em0: port 0xac00-0xac1f mem > 0xface0000-0xfacfffff,0xfacc0000-0xfacdffff irq 16 at device 0.0 on pci1 > > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:78:e6:e0 > em1: port 0xa880-0xa89f mem > 0xfac80000-0xfac9ffff,0xfac60000-0xfac7ffff irq 17 at device 0.1 on pci1 > > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:15:17:78:e6:e1 > pcib2: at device 3.0 on pci0 > pci2: on pcib2 > pcib3: at device 5.0 on pci0 > pci3: on pcib3 > em2: port 0xbc00-0xbc1f mem > 0xfade0000-0xfadfffff,0xfadc0000-0xfaddffff irq 16 at device 0.0 on pci3 > > em2: Using MSI interrupt > em2: [FILTER] > em2: Ethernet address: 00:15:17:cf:26:de > em3: port 0xb880-0xb89f mem > 0xfad80000-0xfad9ffff,0xfad60000-0xfad7ffff irq 17 at device 0.1 on pci3 > > em3: Using MSI interrupt > em3: [FILTER] > em3: Ethernet address: 00:15:17:cf:26:df > pcib4: at device 7.0 on pci0 > pci4: on pcib4 > pcib5: at device 9.0 on pci0 > pci5: on pcib5 > pci0: at device 16.0 (no driver > attached) > pci0: at device 16.1 (no driver > attached) > pci0: at device 20.0 (no driver > attached) > pci0: at device 20.1 (no driver > attached) > pci0: at device 20.2 (no driver > attached) > pci0: at device 20.3 (no driver > attached) > pci0: at device 22.0 (no driver attached) > pci0: at device 22.1 (no driver attached) > pci0: at device 22.2 (no driver attached) > pci0: at device 22.3 (no driver attached) > pci0: at device 22.4 (no driver attached) > pci0: at device 22.5 (no driver attached) > pci0: at device 22.6 (no driver attached) > pci0: at device 22.7 (no driver attached) > uhci0: port 0x9c00-0x9c1f irq 16 at device > 26.0 on pci0 > uhci0: [ITHREAD] > uhci0: LegSup = 0x2f00 > usbus0: on uhci0 > uhci1: port 0x9880-0x989f irq 21 at device > 26.1 on pci0 > uhci1: [ITHREAD] > uhci1: LegSup = 0x2f00 > usbus1: on uhci1 > uhci2: port 0x9800-0x981f irq 19 at device > 26.2 on pci0 > uhci2: [ITHREAD] > uhci2: LegSup = 0x2f00 > usbus2: on uhci2 > ehci0: mem 0xfabde000-0xfabde3ff irq 18 > at device 26.7 on pci0 > ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > pcib6: irq 17 at device 28.0 on pci0 > pci6: on pcib6 > em4: port 0xcc00-0xcc1f mem > 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci6 > > em4: Using MSIX interrupts > em4: [ITHREAD] > em4: [ITHREAD] > em4: [ITHREAD] > em4: Ethernet address: 00:30:48:d6:ef:12 > pcib7: irq 16 at device 28.1 on pci0 > pci7: on pcib7 > em5: port 0xdc00-0xdc1f mem > 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci7 > > em5: Using MSIX interrupts > em5: [ITHREAD] > em5: [ITHREAD] > em5: [ITHREAD] > em5: Ethernet address: 00:30:48:d6:ef:13 > uhci3: port 0x9480-0x949f irq 23 at device > 29.0 on pci0 > uhci3: [ITHREAD] > uhci3: LegSup = 0x2f00 > usbus4: on uhci3 > uhci4: port 0x9400-0x941f irq 19 at device > 29.1 on pci0 > uhci4: [ITHREAD] > uhci4: LegSup = 0x2f00 > usbus5: on uhci4 > uhci5: port 0x9080-0x909f irq 18 at device > 29.2 on pci0 > uhci5: [ITHREAD] > uhci5: LegSup = 0x2f00 > usbus6: on uhci5 > ehci1: mem 0xfabdc000-0xfabdc3ff irq 23 > at device 29.7 on pci0 > ehci1: [ITHREAD] > usbus7: EHCI version 1.0 > usbus7: on ehci1 > pcib8: at device 30.0 on pci0 > pci8: on pcib8 > fxp0: port 0xec00-0xec3f mem > 0xfbefe000-0xfbefefff,0xfbec0000-0xfbedffff irq 17 at device 1.0 on pci8 > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:02:b3:5d:ca:ce > fxp0: [ITHREAD] > vgapci0: mem > 0xf9800000-0xf9ffffff,0xfbef8000-0xfbefbfff,0xfb000000-0xfb7fffff irq 17 at > device 4.0 on pci8 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x9000-0x9007,0x8c00-0x8c03,0x8880-0x8887,0x8800-0x8803,0x8480-0x848f,0x8400-0x840f > irq 19 at device 31.2 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > pci0: at device 31.3 (no driver attached) > atapci1: port > 0x8000-0x8007,0x7c00-0x7c03,0x7880-0x7887,0x7800-0x7803,0x7480-0x748f,0x7400-0x740f > irq 19 at device 31.5 on pci0 > atapci1: [ITHREAD] > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (38400,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 5 on acpi0 > uart2: [FILTER] > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - 8A, should be 87 > 20090521 tbutils-275 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff pnpid > ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x100> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 480Mbps High Speed USB v2.0 > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > ugen1.1: at usbus1ugen0.1: at usbus0Root mount waiting > for:ugen2.1: at usbus2 > > > usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 > uhub0: on usbus0 > ugen3.1: at usbus3uhub1: > on usbus2 > uhub2: on usbus1 > uhub3: on usbus3 > ugen4.1: at usbus4ugen5.1: at usbus5ugen7.1: at > usbus7ugen6.1: at usbus6 > uhub4: > on usbus4 > > uhub5: > on usbus5 > uhub6: on usbus6 > uhub7: on usbus7 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > Root mount waiting for: usbus7 usbus3 > Root mount waiting for: usbus7 usbus3 > uhub3: 6 ports with 6 removable, self powered > uhub7: 6 ports with 6 removable, self powered > Trying to mount root from nfs:10.255.255.1:/home/pxe > NFS ROOT: 10.255.255.1:/usr/home/pxe/ > > > ---Mike > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From freebsd at jdc.parodius.com Thu Nov 19 18:29:00 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 19 18:29:08 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <200911191433.nAJEXqqT095949@lava.sentex.ca> References: <4B0552B2.2020000@denninger.net> <200911191427.nAJERSl6095906@lava.sentex.ca> <4B0555CD.8050704@denninger.net> <200911191433.nAJEXqqT095949@lava.sentex.ca> Message-ID: <20091119182858.GA47308@icarus.home.lan> On Thu, Nov 19, 2009 at 09:34:01AM -0500, Mike Tancsa wrote: > At 09:27 AM 11/19/2009, Karl Denninger wrote: > >It's not. > > > >What does that do? > > From the man page, > > With flags encoded as: > 0x00010 device is potential system console > 0x00080 use this port for remote kernel debugging > 0x00100 set RX FIFO trigger level to ``low'' (NS8250 only) > 0x00200 set RX FIFO trigger level to ``medium low'' (NS8250 only) > 0x00400 set RX FIFO trigger level to ``medium high'' (default, NS8250 > only) > 0x00800 set RX FIFO trigger level to ``high'' (NS8250 only) > > You might still want to try adjusting how fast the FIFOs are flushed > to see if thats your issue. Has anyone considered involving Marcel Moolenaar in this conversation, given that he's responsible for uart(4)? :-) I've CC'd him here. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From matthew.fleming at isilon.com Thu Nov 19 18:48:11 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Thu Nov 19 18:48:17 2009 Subject: LRO support for cxgb in stable/7 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E03390417@seaxch09.desktop.isilon.com> r193754 to stable/7 appears to have unintended code. The MFC note indicates it is a backport of 190206, 190330, 192537, 192540, 192584 and 192933. I looked over all of them and none have the offending snippet: #ifndef LRO_SUPPORTED #ifdef IFCAP_LRO #undef IFCAP_LRO #endif #define IFCAP_LRO 0x0 #endif cxgb had LRO support on releng/7.1 and now it does not, since LRO_SUPPORTED is not defined anywhere as a config option, or in the cxgb Makefile. Is this analysis correct? Should the above lines be deleted from the stable/7 repository? Thanks, matthew From nparhar at gmail.com Thu Nov 19 20:32:49 2009 From: nparhar at gmail.com (Navdeep Parhar) Date: Thu Nov 19 20:32:56 2009 Subject: LRO support for cxgb in stable/7 In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E03390417@seaxch09.desktop.isilon.com> References: <06D5F9F6F655AD4C92E28B662F7F853E03390417@seaxch09.desktop.isilon.com> Message-ID: <20091119203240.GA32312@doormat.home> On Thu, Nov 19, 2009 at 10:48:40AM -0800, Matthew Fleming wrote: > r193754 to stable/7 appears to have unintended code. The MFC note > indicates it is a backport of 190206, 190330, 192537, 192540, 192584 and > 192933. I looked over all of them and none have the offending snippet: > > #ifndef LRO_SUPPORTED > #ifdef IFCAP_LRO > #undef IFCAP_LRO > #endif > #define IFCAP_LRO 0x0 > #endif > > cxgb had LRO support on releng/7.1 and now it does not, since > LRO_SUPPORTED is not defined anywhere as a config option, or in the cxgb > Makefile. > > Is this analysis correct? Should the above lines be deleted from the > stable/7 repository? You're correct. This has now been fixed in r199544. Regards, Navdeep > > Thanks, > matthew > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From randy at psg.com Fri Nov 20 00:45:30 2009 From: randy at psg.com (Randy Bush) Date: Fri Nov 20 00:45:37 2009 Subject: 7.2 dies in midnight run again References: Message-ID: i think the issue is how to tune for zfs i386 with 4G of RAM RELENG_7 cvsupped Nov 18 02:42 GMT panic: kmem_malloc(65536): kmem_map too small: 535019520 total allocated cpuid = 0 Uptime: 13h15m1s Physical memory: 3958 MB Dumping 637 MB: 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort and it did not auto reboot # cat /boot/loader.conf.local ipfw_load=YES umass_load=YES zfs_load=YES vm.kmem_size=536870912 vm.kmem_size_max=1073741824 vfs.zfs.prefetch_disable=1 it has zfs # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 twed1 ONLINE 0 0 0 twed2 ONLINE 0 0 0 errors: No known data errors but boots and has root on ufs # df -H Filesystem Size Used Avail Capacity Mounted on /dev/twed0s1a 260M 199M 40M 83% / devfs 1.0k 1.0k 0B 100% /dev /dev/twed0s1h 65M 2.3M 57M 4% /root procfs 4.1k 4.1k 0B 100% /proc tank 147G 17M 147G 0% /tank tank/usr 167G 20G 147G 12% /usr tank/usr/home 216G 68G 147G 32% /usr/home tank/var 149G 2.3G 147G 2% /var tank/var/spool 148G 531M 147G 0% /var/spool /dev/md0 130M 12k 119M 0% /tmp # kgdb kernel.debug /usr/home/crash/vmcore.20 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: kmem_malloc(65536): kmem_map too small: 535019520 total allocated cpuid = 0 Uptime: 13h15m1s Physical memory: 3958 MB Dumping 637 MB: 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko Reading symbols from /boot/kernel/cam.ko...Reading symbols from /boot/kernel/cam.ko.symbols...done. done. Loaded symbols for /boot/kernel/cam.ko Reading symbols from /boot/kernel/usb.ko...Reading symbols from /boot/kernel/usb.ko.symbols...done. done. Loaded symbols for /boot/kernel/usb.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) back #0 doadump () at pcpu.h:196 #1 0xc052b0b6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc052b39e in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06dfb54 in kmem_malloc (map=0xc107108c, size=65536, flags=2) at /usr/src/sys/vm/vm_kern.c:305 #4 0xc06d6317 in page_alloc (zone=0x0, bytes=65536, pflag=0xf67ee4a7 "\002", wait=2) at /usr/src/sys/vm/uma_core.c:952 #5 0xc06d8e20 in uma_large_malloc (size=65536, wait=2) at /usr/src/sys/vm/uma_core.c:2706 #6 0xc05189e8 in malloc (size=65536, mtp=0xc0989060, flags=2) at /usr/src/sys/kern/kern_malloc.c:393 #7 0xc0897a61 in zfs_kmem_alloc (size=65536, kmflags=2) at /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:74 #8 0xc090bf4a in zio_buf_alloc (size=65536) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:207 #9 0xc08f3472 in vdev_cache_read (zio=0xd39d0708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_cache.c:188 #10 0xc090c145 in zio_vdev_io_start (zio=0xd39d0708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1816 #11 0xc090c7f0 in zio_execute (zio=0xd39d0708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #12 0xc08f6bda in vdev_mirror_io_start (zio=0xd77e7708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:303 #13 0xc090c7f0 in zio_execute (zio=0xd77e7708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #14 0xc08f6bda in vdev_mirror_io_start (zio=0xdbd22960) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:303 #15 0xc090c7f0 in zio_execute (zio=0xdbd22960) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #16 0xc08ad39d in arc_read_nolock (pio=0xd1844960, spa=0xc7746000, bp=0xcc548640, done=0xc08b0600 , private=0xd9c89e38, priority=0, zio_flags=1, arc_flags=0xf67ee854, zb=0xf67ee834) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2762 #17 0xc08ad878 in arc_read (pio=0xd1844960, spa=0xc7746000, bp=0xcc548640, pbuf=0xc9b29134, done=0xc08b0600 , private=0xd9c89e38, priority=0, zio_flags=1, arc_flags=0xf67ee854, zb=0xf67ee834) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2507 #18 0xc08b0ada in dbuf_read (db=0xd9c89e38, zio=0xd1844960, flags=14) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:521 #19 0xc08b1142 in dbuf_findbp (dn=0xcba92000, level=Variable "level" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1381 #20 0xc08b1269 in dbuf_hold_impl (dn=0xcba92000, level=0 '\0', blkid=0, fail_sparse=0, tag=0x0, dbp=0xf67ee8f0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1617 #21 0xc08b2529 in dbuf_hold (dn=0xcba92000, blkid=0, tag=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1689 #22 0xc08b48cc in dmu_buf_hold (os=0xc774b3d0, object=167123, offset=0, tag=0x0, dbp=0xf67ee95c) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:101 #23 0xc0900044 in zap_lockdir (os=0xc774b3d0, obj=167123, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=0xf67eeba0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:388 #24 0xc09009fd in zap_cursor_retrieve (zc=0xf67eeb9c, za=0xf67eea84) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1004 #25 0xc0925a2b in zfs_freebsd_readdir (ap=0xf67eec00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2156 #26 0xc07382f2 in VOP_READDIR_APV (vop=0xc098b560, a=0xf67eec00) at vnode_if.c:1407 #27 0xc05becae in kern_getdirentries (td=0xd5a01000, fd=19, buf=0x29061000
, count=4096, basep=0xf67eec74) at vnode_if.h:747 #28 0xc05beec1 in getdirentries (td=0xd5a01000, uap=0xf67eecfc) at /usr/src/sys/kern/vfs_syscalls.c:3776 #29 0xc072cfc5 in syscall (frame=0xf67eed38) at /usr/src/sys/i386/i386/trap.c:1101 #30 0xc0711380 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #31 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) randy From doconnor at gsoft.com.au Fri Nov 20 00:48:33 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Fri Nov 20 00:49:46 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <2e027be00911190444s1ce5f297o9064bb9c0d28ef30@mail.gmail.com> References: <200911192305.35337.doconnor@gsoft.com.au> <2e027be00911190444s1ce5f297o9064bb9c0d28ef30@mail.gmail.com> Message-ID: <200911201118.26242.doconnor@gsoft.com.au> On Thu, 19 Nov 2009, Tom Evans wrote: > On Thu, Nov 19, 2009 at 12:35 PM, Daniel O'Connor wrote: > > On Thu, 19 Nov 2009, Marius N?nnerich wrote: > > > > operator 0, 164 Oct 21 15:34 > > > > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > > > > > > Have you tried naming the GPT partitions and using /dev/gpt/* ? > > > > Nope, how would I do that? > > > > I'd be surprised if it worked TBH.. > > Use the -l flag to gpart when creating the partitions. I'm not sure > if there is a way to label them after the fact. I found it led to a > much more descriptive/reliable pool, as I can plug the disks in > anywhere and get the same results: Descriptive yes, reliable no (IMO :) UUIDs should always be more reliable so long as the "UU" part of their name holds true :) No reason you couldn't have both thought. > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/samsung15-1 ONLINE 0 0 0 > gpt/samsung15-2 ONLINE 0 0 0 > gpt/samsung15-3 ONLINE 0 0 0 > gpt/samsung15-4 ONLINE 0 0 0 > gpt/seagate15-1 ONLINE 0 0 0 > gpt/seagate15-2 ONLINE 0 0 0 > > I use the geom name 'gpt/foo' when referring to the disks in zpool. > All works perfectly. Hmm I did.. [midget 11:13] ~ >sudo gpart modify -i 2 -l "Midget-ZFS-1" ad4 ad4p2 modified [midget 11:15] ~ >sudo gpart show -l ad4 => 34 1953525101 ad4 GPT (932G) 34 8388608 1 (null) (4.0G) 8388642 1944059904 2 Midget-ZFS-1 (927G) 1952448546 1076589 - free - (526M) but I get no /dev/gpt directory.. [midget 11:14] ~ >ls -la /dev/gpt ls: /dev/gpt: No such file or directory Maybe the UUID label got their first so it won't have an alias (although the UUID is an alias for /dev/ad4p2..) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091120/2a1f38cc/attachment.pgp From gaijin.k at gmail.com Fri Nov 20 03:43:49 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Fri Nov 20 03:43:56 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <4B03322A.2080608@FreeBSD.org> References: <4B03322A.2080608@FreeBSD.org> Message-ID: <1258688373.1678.4.camel@RabbitsDen> On Wed, 2009-11-18 at 01:30 +0200, Alexander Motin wrote: > Feedbacks are welcome as always. > Works here (ThinkPad X60): ahci0: port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xee444400-0xee4447ff irq 16 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 RabbitsDen# camcontrol tags ada0 (pass0:ahcich0:0:0:0): device openings: 32 RabbitsDen# Thank you for doing this work. -- Alexandre Kovalenko (????????? ?????????) From perryh at pluto.rain.com Fri Nov 20 08:11:01 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Fri Nov 20 08:11:08 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <4B054F6D.70300@denninger.net> References: <4B054DCC.6020701@denninger.net> <200911191357.nAJDvd3X095748@lava.sentex.ca> <4B054F6D.70300@denninger.net> Message-ID: <4b064f08.QD1V6fZm4C5kf4Qb%perryh@pluto.rain.com> Karl Denninger wrote: > ... the uart driver is BROKEN. > > It simply locks up on the port after some period of time, > returning nothing. I have found no way to reset the port > other than a reboot either ... Welcome to the distant past. I'll be interested to see what the root cause turns out to be. I've seen the same symptoms on: * A Sun-3/50 running SunOS 4.1.1_U1, using ttyb; * A Sun Ultra 2 running (IIRC) Solaris 2.5, using an Aurora multi-port S-Bus card; * A Sun Ultra 10, using an Aurora multi-port PCI card. The Suns were using Aurora drivers. I was never able to get one of those systems' ttya or ttyb (using Sun drivers, of course) to hang that way. From se at freebsd.org Fri Nov 20 10:38:30 2009 From: se at freebsd.org (Stefan Esser) Date: Fri Nov 20 10:38:45 2009 Subject: 7.2 dies in midnight run again In-Reply-To: References: Message-ID: <4B066B13.1070006@freebsd.org> Am 20.11.2009 01:45, schrieb Randy Bush: > i think the issue is how to tune for zfs > > i386 with 4G of RAM > > RELENG_7 cvsupped Nov 18 02:42 GMT > > panic: kmem_malloc(65536): kmem_map too small: 535019520 total allocated > cpuid = 0 > Uptime: 13h15m1s > Physical memory: 3958 MB > Dumping 637 MB: 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 > Dump complete > Automatic reboot in 15 seconds - press a key on the console to abort > > and it did not auto reboot > > # cat /boot/loader.conf.local > ipfw_load=YES > umass_load=YES > zfs_load=YES > vm.kmem_size=536870912 > vm.kmem_size_max=1073741824 > vfs.zfs.prefetch_disable=1 I'm using 8.0-i386 (but AFAIK with same ZFS and allocation behaviour) on a system with 2GB RAM and a RAIDZ1 consisting of 3*1TB (plus separate 10GB L2ARC cache on a separate disk, to become a SSD). Besides increasing KVA_PAGES to cover some 2GB (options KVA_PAGES=512), I use: vm.kmem_size=1500M vm.kmem_size_max=2G This is the result of quite some tuning, since I also suffered from kmem_map too small panics under high load. BTW: I use auto-tuning of the ARC cache size: vfs.zfs.arc_min: 122880000 vfs.zfs.arc_max: 983040000 Due to the extra ZFS cache drive, I could reduce arc_max to some 300MB (or even lower, Though I did not test lower values, yet), without noticeable impact (faster than with just a 700MB RAM cache in many tests). And since L2ARC caches can be removed from pools at any time and do not need redundancy, it is quite simple to test the effect ... Regards, STefan From marius at nuenneri.ch Fri Nov 20 11:20:26 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Nov 20 11:20:33 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200911201118.26242.doconnor@gsoft.com.au> References: <200911192305.35337.doconnor@gsoft.com.au> <2e027be00911190444s1ce5f297o9064bb9c0d28ef30@mail.gmail.com> <200911201118.26242.doconnor@gsoft.com.au> Message-ID: On Fri, Nov 20, 2009 at 01:48, Daniel O'Connor wrote: > On Thu, 19 Nov 2009, Tom Evans wrote: >> On Thu, Nov 19, 2009 at 12:35 PM, Daniel O'Connor > wrote: >> > On Thu, 19 Nov 2009, Marius N?nnerich wrote: >> > > > ?operator ? ?0, 164 Oct 21 15:34 >> > > > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc >> > > >> > > Have you tried naming the GPT partitions and using /dev/gpt/* ? >> > >> > Nope, how would I do that? >> > >> > I'd be surprised if it worked TBH.. >> >> Use the -l flag to gpart when creating the partitions. I'm not sure >> if there is a way to label them after the fact. I found it led to a >> much more descriptive/reliable pool, as I can plug the disks in >> anywhere and get the same results: > > Descriptive yes, reliable no (IMO :) > > UUIDs should always be more reliable so long as the "UU" part of their > name holds true :) > > No reason you couldn't have both thought. > >> ? pool: tank >> ?state: ONLINE >> ?scrub: none requested >> config: >> >> ? ? NAME ? ? ? ? ? ? ? ? ?STATE ? ? READ WRITE CKSUM >> ? ? tank ? ? ? ? ? ? ? ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? raidz1 ? ? ? ? ? ? ?ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? gpt/samsung15-1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? gpt/samsung15-2 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? gpt/samsung15-3 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? gpt/samsung15-4 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? gpt/seagate15-1 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> ? ? ? ? gpt/seagate15-2 ? ONLINE ? ? ? 0 ? ? 0 ? ? 0 >> >> I use the geom name 'gpt/foo' when referring to the disks in zpool. >> All works perfectly. > > Hmm I did.. > [midget 11:13] ~ >sudo gpart modify -i 2 -l "Midget-ZFS-1" ad4 > ad4p2 modified > [midget 11:15] ~ >sudo gpart show -l ad4 > => ? ? ? ?34 ?1953525101 ?ad4 ?GPT ?(932G) > ? ? ? ? ?34 ? ? 8388608 ? ?1 ?(null) ?(4.0G) > ? ? 8388642 ?1944059904 ? ?2 ?Midget-ZFS-1 ?(927G) > ?1952448546 ? ? 1076589 ? ? ? - free - ?(526M) > > but I get no /dev/gpt directory.. > [midget 11:14] ~ >ls -la /dev/gpt > ls: /dev/gpt: No such file or directory > > Maybe the UUID label got their first so it won't have an alias (although > the UUID is an alias for /dev/ad4p2..) Maybe that's been asked already but what version are you using? Does glabel work at all? From gerrit at pmp.uni-hannover.de Fri Nov 20 12:29:49 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Fri Nov 20 12:29:57 2009 Subject: zfs/nfs mkstemp() failure & subsequent hangs Message-ID: <20091120132945.e2031bfb.gerrit@pmp.uni-hannover.de> Hi all, I have a 8.0-PRERELEASE zfs/nfs server here that complains about i/o errors when using rsync on a nfs client: rsync: mkstemp "/usr/portage/metadata/cache/app-mobilephone/.ksms-0.1.2.4.BynVFw" failed: Input/output error (5) I found this to be quite similar to kern/135412. However, this one is said to be fixed and only applicable to 7-stable anyway. Furthermore, after this happened, I tried to access files on the server from the zfs filesystem concerned and found that I cannot access the fs anymore. ls hangs in state zfs, so do mountd and zfs unmount. Questions: Should I open a new PR for this? Are there any ideas how to recover access to the fs apart from rebooting the machine? Right now I still have it running, so I could get some more debugging information out of it. cu Gerrit From doconnor at gsoft.com.au Fri Nov 20 12:32:32 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Fri Nov 20 12:32:39 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: <200911201118.26242.doconnor@gsoft.com.au> Message-ID: <200911202302.24794.doconnor@gsoft.com.au> On Fri, 20 Nov 2009, Marius N?nnerich wrote: > > Maybe the UUID label got their first so it won't have an alias > > (although the UUID is an alias for /dev/ad4p2..) > > Maybe that's been asked already but what version are you using? > Does glabel work at all? 8.0-RC1 glabel works fine, I use it for swap. Actually that is an interesting point, the swap partitions don't have an entry in /dev/gptid, although perhaps that is because glabel has grabbed that node. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091120/9d4850a5/attachment.pgp From marius at nuenneri.ch Fri Nov 20 12:36:39 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Nov 20 12:36:46 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200911202302.24794.doconnor@gsoft.com.au> References: <200911201118.26242.doconnor@gsoft.com.au> <200911202302.24794.doconnor@gsoft.com.au> Message-ID: On Fri, Nov 20, 2009 at 13:32, Daniel O'Connor wrote: > On Fri, 20 Nov 2009, Marius N?nnerich wrote: >> > Maybe the UUID label got their first so it won't have an alias >> > (although the UUID is an alias for /dev/ad4p2..) >> >> Maybe that's been asked already but what version are you using? >> Does glabel work at all? > > 8.0-RC1 > > glabel works fine, I use it for swap. > > Actually that is an interesting point, the swap partitions don't have an > entry in /dev/gptid, although perhaps that is because glabel has > grabbed that node. If I remember correctly nodes vanish when another name for the same device is opened. Maybe this happens for the other gpt labels too? From karl at denninger.net Fri Nov 20 12:40:23 2009 From: karl at denninger.net (Karl Denninger) Date: Fri Nov 20 12:40:30 2009 Subject: V8.x-PRE2 Serious PUC problem - Heads Up! In-Reply-To: <4b064f08.QD1V6fZm4C5kf4Qb%perryh@pluto.rain.com> References: <4B054DCC.6020701@denninger.net> <200911191357.nAJDvd3X095748@lava.sentex.ca> <4B054F6D.70300@denninger.net> <4b064f08.QD1V6fZm4C5kf4Qb%perryh@pluto.rain.com> Message-ID: <4B068DD4.1010301@denninger.net> perryh@pluto.rain.com wrote: > Karl Denninger wrote: > >> ... the uart driver is BROKEN. >> >> It simply locks up on the port after some period of time, >> returning nothing. I have found no way to reset the port >> other than a reboot either ... >> > > Welcome to the distant past. I'll be interested to see what > the root cause turns out to be. > > I've seen the same symptoms on: > > * A Sun-3/50 running SunOS 4.1.1_U1, using ttyb; > > * A Sun Ultra 2 running (IIRC) Solaris 2.5, > using an Aurora multi-port S-Bus card; > > * A Sun Ultra 10, using an Aurora multi-port PCI card. > > The Suns were using Aurora drivers. I was never able to get one of > those systems' ttya or ttyb (using Sun drivers, of course) to hang > that way. I know. These sorts of problems remind me of the 90s.... and 80s.... :) I've managed to put the fire out by rolling back to 7.1, but obviously this isn't a long-term solution. I'll get back on it over the weekend and during Turkey Week - my "best guess" is that there's some sort of problem with buffering somewhere. Missed interrupts should not be a factor on a PCI interface (as was occasionally an issue with the old ISA cards) but the lack of a way to poke a port and reset it elevates something like this from highly irritating to a serious issue. Finding the problem isn't going to be easy either... -- Karl From mikael at t-online.hu Fri Nov 20 12:57:58 2009 From: mikael at t-online.hu (Mikael Bak) Date: Fri Nov 20 12:58:06 2009 Subject: Recommendations on when to use soft updates Message-ID: <4B069254.7080709@t-online.hu> Hi list, I'm quite new to FreeBSD. I would like to know if there are any official recommendations on when to use soft updates and when not to use them. I currently maintain only one FreeBSD machine. $ uname -v FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 08:22:32 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC I have two identical SATA disks in a raid1 using gmirror like this: $ df -h Filesystem Size Used Avail Capacity Mounted on /dev/mirror/gm0s1a 3.9G 303M 3.3G 8% / devfs 1.0K 1.0K 0B 100% /dev /dev/mirror/gm0s1d 989M 1.0M 909M 0% /tmp /dev/mirror/gm0s1e 48G 1.7G 43G 4% /usr /dev/mirror/gm0s1f 53G 1.2G 48G 2% /var devfs 1.0K 1.0K 0B 100% /var/named/dev Currently /usr and /var uses soft updates, but / does not. The machine acts as a front MX with lots of reads and writes in /var. Is this a reasonable setup? TIA, Mikael From doconnor at gsoft.com.au Fri Nov 20 13:27:57 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Fri Nov 20 13:28:04 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: <200911202302.24794.doconnor@gsoft.com.au> Message-ID: <200911202357.48622.doconnor@gsoft.com.au> On Fri, 20 Nov 2009, Marius N?nnerich wrote: > > Actually that is an interesting point, the swap partitions don't > > have an entry in /dev/gptid, although perhaps that is because > > glabel has grabbed that node. > > If I remember correctly nodes vanish when another name for the same > device is opened. Maybe this happens for the other gpt labels too? Hmm, but I have gptid ones corresponding to my ZFS partitions.. It seems like a bug. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091120/3d1c98e4/attachment.pgp From marius at nuenneri.ch Fri Nov 20 13:31:04 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Nov 20 13:31:10 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200911202357.48622.doconnor@gsoft.com.au> References: <200911202302.24794.doconnor@gsoft.com.au> <200911202357.48622.doconnor@gsoft.com.au> Message-ID: On Fri, Nov 20, 2009 at 14:27, Daniel O'Connor wrote: > On Fri, 20 Nov 2009, Marius N?nnerich wrote: >> > Actually that is an interesting point, the swap partitions don't >> > have an entry in /dev/gptid, although perhaps that is because >> > glabel has grabbed that node. >> >> If I remember correctly nodes vanish when another name for the same >> device is opened. Maybe this happens for the other gpt labels too? > > Hmm, but I have gptid ones corresponding to my ZFS partitions.. It seems > like a bug. Maybe. Could you paste kern.geom.confdot, kern.geom.confxml and mount output to pastie.org or the like. From jhb at freebsd.org Fri Nov 20 14:41:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 20 14:42:06 2009 Subject: Recommendations on when to use soft updates In-Reply-To: <4B069254.7080709@t-online.hu> References: <4B069254.7080709@t-online.hu> Message-ID: <200911200941.29277.jhb@freebsd.org> On Friday 20 November 2009 7:57:56 am Mikael Bak wrote: > Hi list, > > I'm quite new to FreeBSD. > I would like to know if there are any official recommendations on when > to use soft updates and when not to use them. > > I currently maintain only one FreeBSD machine. > > $ uname -v > FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 08:22:32 UTC 2009 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > > I have two identical SATA disks in a raid1 using gmirror like this: > > $ df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/mirror/gm0s1a 3.9G 303M 3.3G 8% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/mirror/gm0s1d 989M 1.0M 909M 0% /tmp > /dev/mirror/gm0s1e 48G 1.7G 43G 4% /usr > /dev/mirror/gm0s1f 53G 1.2G 48G 2% /var > devfs 1.0K 1.0K 0B 100% /var/named/dev > > Currently /usr and /var uses soft updates, but / does not. > > The machine acts as a front MX with lots of reads and writes in /var. > > Is this a reasonable setup? Yes. -- John Baldwin From lab at gta.com Fri Nov 20 14:44:29 2009 From: lab at gta.com (Larry Baird) Date: Fri Nov 20 14:44:36 2009 Subject: Most files in subversion stable/8/sys touched by bms Message-ID: <20091120144428.GA27644@gta.com> I use the following to get a feel of what is changing in FreeBSD 8 kernel. http://svn.freebsd.org/viewvc/base/stable/8/sys/?sortby=date Normally only a few directories show modification. Today, almost every directory show a modification by bms: MFC r199522..199528: Pullup IPv6 mcast SSM KPI fixes from HEAD, including fix . So I decided to see what the changes are. Every file I have so far checked shows no changes. http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/cons.h?r1=196045&r2=199578&sortby=date Any idea why so many files claim to have been touched? Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From dimitry at andric.com Fri Nov 20 15:56:45 2009 From: dimitry at andric.com (Dimitry Andric) Date: Fri Nov 20 15:56:54 2009 Subject: Most files in subversion stable/8/sys touched by bms In-Reply-To: <20091120144428.GA27644@gta.com> References: <20091120144428.GA27644@gta.com> Message-ID: <4B06BC3C.5040804@andric.com> On 2009-11-20 15:44, Larry Baird wrote: > I use the following to get a feel of what is changing in FreeBSD 8 kernel. > http://svn.freebsd.org/viewvc/base/stable/8/sys/?sortby=date > > Normally only a few directories show modification. Today, almost > every directory show a modification by bms: > MFC r199522..199528: Pullup IPv6 mcast SSM KPI fixes from HEAD, including fix . > > So I decided to see what the changes are. Every file I have so far checked > shows no changes. > http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/cons.h?r1=196045&r2=199578&sortby=date > > Any idea why so many files claim to have been touched? Usually this is mergeinfo propagated by Subversion. The files' contents did not change, but its metadata (Subversion properties) did. From lab at gta.com Fri Nov 20 16:09:58 2009 From: lab at gta.com (Larry Baird) Date: Fri Nov 20 16:10:04 2009 Subject: Most files in subversion stable/8/sys touched by bms In-Reply-To: <4B06BC3C.5040804@andric.com> References: <20091120144428.GA27644@gta.com> <4B06BC3C.5040804@andric.com> Message-ID: <20091120160955.GA47889@gta.com> On Fri, Nov 20, 2009 at 04:56:44PM +0100, Dimitry Andric wrote: > On 2009-11-20 15:44, Larry Baird wrote: > > I use the following to get a feel of what is changing in FreeBSD 8 kernel. > > http://svn.freebsd.org/viewvc/base/stable/8/sys/?sortby=date > > > > Normally only a few directories show modification. Today, almost > > every directory show a modification by bms: > > MFC r199522..199528: Pullup IPv6 mcast SSM KPI fixes from HEAD, including fix . > > > > So I decided to see what the changes are. Every file I have so far checked > > shows no changes. > > http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/cons.h?r1=196045&r2=199578&sortby=date > > > > Any idea why so many files claim to have been touched? > > Usually this is mergeinfo propagated by Subversion. The files' contents > did not change, but its metadata (Subversion properties) did. I also noticed that if you check out the base/stable/8/sys tree that most of the $FreeBSD$ id strings are also modified. $FreeBSD: stable/8/sys/sys/socket.h 199578 2009-11-20 12:30:40Z bms Looking at the subversion tree, jhb is tring to cleanup mergeinfo. Hopefully he will have luck. (-: Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From matt at madhaus.cns.utoronto.ca Fri Nov 20 18:40:04 2009 From: matt at madhaus.cns.utoronto.ca (Matt Wilks) Date: Fri Nov 20 18:40:13 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> Message-ID: <4B06E274.3090207@madhaus.cns.utoronto.ca> Just a note of closure. Apparently NSIS doesn't compile on 64-bit architectures. Compiled fine on an i386 7.2 install (same machine), once the proper library paths were provided. Matt Wilks wrote: > I'm attempting to install NSIS (http://nsis.sourceforge.net/) on an > amd64 FreeBSD 7.2 system and having trouble. When I run > > scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all > NSIS_CONFIG_CONST_DATA_PATH=no > > in the source directory for NSIS, I get a bunch of errors that look like: > > /usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t' > ('unsigned int') as first parameter > > A google search gives me a link to this bug > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582 that doesn't seem to > have been touched since 2006. Is there someway around this compile error? > > Thanks, > Matt > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Matt Wilks Colossians 2:6-7 University of Toronto Information Security, I+TS (416) 978-3328 matt@madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1 From freebsd at jdc.parodius.com Fri Nov 20 19:46:16 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Fri Nov 20 19:46:25 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <4B06E274.3090207@madhaus.cns.utoronto.ca> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> <4B06E274.3090207@madhaus.cns.utoronto.ca> Message-ID: <20091120194613.GA81572@icarus.home.lan> On Fri, Nov 20, 2009 at 01:39:48PM -0500, Matt Wilks wrote: > Just a note of closure. Apparently NSIS doesn't compile on 64-bit > architectures. Compiled fine on an i386 7.2 install (same machine), > once the proper library paths were provided. > > Matt Wilks wrote: > >I'm attempting to install NSIS (http://nsis.sourceforge.net/) on > >an amd64 FreeBSD 7.2 system and having trouble. When I run > > > >scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all > >NSIS_CONFIG_CONST_DATA_PATH=no > > > >in the source directory for NSIS, I get a bunch of errors that look like: > > > >/usr/include/c++/4.2/new:95: error: 'operator new' takes type > >'size_t' ('unsigned int') as first parameter > > > >A google search gives me a link to this bug > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28582 that doesn't > >seem to have been touched since 2006. Is there someway around > >this compile error? > > > >Thanks, > >Matt If that's indeed the case, then the port Makefile needs to be modified to reject building on any architectures other than i386. This should suffice: ONLY_FOR_ARCHS= i386 If you could file a PR on this matter, the FreeBSD Project folks would likely appreciate it. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From doconnor at gsoft.com.au Fri Nov 20 22:21:16 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Fri Nov 20 22:21:24 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: <200911202357.48622.doconnor@gsoft.com.au> Message-ID: <200911210851.04678.doconnor@gsoft.com.au> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091120/30552fe2/attachment.pgp From linimon at lonesome.com Fri Nov 20 23:21:20 2009 From: linimon at lonesome.com (Mark Linimon) Date: Fri Nov 20 23:21:27 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <20091120194613.GA81572@icarus.home.lan> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> <4B06E274.3090207@madhaus.cns.utoronto.ca> <20091120194613.GA81572@icarus.home.lan> Message-ID: <20091120230525.GA11504@lonesome.com> On Fri, Nov 20, 2009 at 11:46:13AM -0800, Jeremy Chadwick wrote: > If that's indeed the case, then the port Makefile needs to be modified > to reject building on any architectures other than i386. This should > suffice: > > ONLY_FOR_ARCHS= i386 There's a (fine?) distinction between the usage of IGNORE (which *_FOR_ARCHS drives) and BROKEN. The former is more of a statement of "it will never work"; the latter is more of a statement of "it doesn't work right now." So, in my own patches for e.g. sparc64, I use .if ${ARCH} == "sparc64" BROKEN= Does not compile on sparc64 .endif unless the port bails out of config with "arch not supported", or it's clearly i386-hardware-related, or something like that. I recognize that this may be a matter of personal taste. mcl From randy at psg.com Sat Nov 21 00:47:59 2009 From: randy at psg.com (Randy Bush) Date: Sat Nov 21 00:48:06 2009 Subject: 7.2 dies in zfs In-Reply-To: <4B066B13.1070006@freebsd.org> References: <4B066B13.1070006@freebsd.org> Message-ID: > vm.kmem_size=1500M > vm.kmem_size_max=2G i am trying this with some success. let's see how the day goes. > BTW: I use auto-tuning of the ARC cache size: > vfs.zfs.arc_min: 122880000 > vfs.zfs.arc_max: 983040000 how the hell is a sysadmin supposed to guess all this ? if the freebsd sysadmin needs to comb through 42 threads on the MLs, read wikis with no clear "do this," and play with trial and error, this stuff is just not going to fly. imiho, zfs can not be called production ready if it crashes if you do not stand on your left leg, put your right hand in the air, and burn some eye of newt. randy From svein-listmail at stillbilde.net Sat Nov 21 01:23:11 2009 From: svein-listmail at stillbilde.net (Svein Skogen (listmail account)) Date: Sat Nov 21 01:23:19 2009 Subject: 7.2 dies in zfs In-Reply-To: References: <4B066B13.1070006@freebsd.org> Message-ID: <4B0740FF.6050302@stillbilde.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randy Bush wrote: > > imiho, zfs can not be called production ready if it crashes if you do > not stand on your left leg, put your right hand in the air, and burn > some eye of newt. That just about sums up my impression. Nine out of ten for porting the code. one out of hundred for the documentation. ZFS works, when you actually get it up and running (after sorting out the various tuning quirks it needs, such as limiting the arc cache so other processes don't time out when it flushes the cache), but it DEFINITELY needs a little more spitshine in the documentation department. Along with manpages that don't refer to sun manpages never going into FreeBSD. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg ?stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksHQP8ACgkQODUnwSLUlKQfYgCfcTFaAq2bj6LxrStTbHeKgNQM WSEAn12/CV8mj+ERf74S2pc7QrYAPgN4 =RRbt -----END PGP SIGNATURE----- From perryh at pluto.rain.com Sat Nov 21 09:10:56 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sat Nov 21 09:11:03 2009 Subject: 7.2 dies in zfs In-Reply-To: References: <4B066B13.1070006@freebsd.org> Message-ID: <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> Randy Bush wrote: > imiho, zfs can not be called production ready if it crashes if you > do not stand on your left leg, put your right hand in the air, and > burn some eye of newt. ROFL! As with any open-source project, I suppose it will be ready when it is ready. At least it hasn't been made the default. From marius at nuenneri.ch Sat Nov 21 11:58:10 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Sat Nov 21 11:58:17 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200911210851.04678.doconnor@gsoft.com.au> References: <200911202357.48622.doconnor@gsoft.com.au> <200911210851.04678.doconnor@gsoft.com.au> Message-ID: On Fri, Nov 20, 2009 at 23:20, Daniel O'Connor wrote: > On Sat, 21 Nov 2009, Marius N?nnerich wrote: >> On Fri, Nov 20, 2009 at 14:27, Daniel O'Connor > wrote: >> > On Fri, 20 Nov 2009, Marius N?nnerich wrote: >> >> > Actually that is an interesting point, the swap partitions don't >> >> > have an entry in /dev/gptid, although perhaps that is because >> >> > glabel has grabbed that node. >> >> >> >> If I remember correctly nodes vanish when another name for the >> >> same device is opened. Maybe this happens for the other gpt labels >> >> too? >> > >> > Hmm, but I have gptid ones corresponding to my ZFS partitions.. It >> > seems like a bug. >> >> Maybe. Could you paste kern.geom.confdot, kern.geom.confxml and mount >> output to pastie.org or the like. > > I've attached it.. Hmm, I do not see whats wrong here. ZFS already opened the devices and I see no /dev/gpt/* entries. Maybe there is some bug with handling the long gptid names. Maybe you try to detach ZFSfrom the devices, give everything a short gpt label and try to use that. From Johan at double-l.nl Sat Nov 21 19:07:40 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Sat Nov 21 19:07:47 2009 Subject: 7.2 dies in zfs References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> Randy Bush wrote: > imiho, zfs can not be called production ready if it crashes if you > do not stand on your left leg, put your right hand in the air, and > burn some eye of newt. This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has been marked as production ready. As far as i know, on FreeBSD 8.0 ZFS is called production ready. If you boot your system it probably tell you it is still experimental. Try running FreeBSD 7-Stable to get the latest ZFS version which on FreeBSD is 13 On 7.2 it is still at 6 (if I remember it right). Regards, Johan Hendriks From freebsd at jdc.parodius.com Sat Nov 21 19:36:46 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Sat Nov 21 19:36:54 2009 Subject: 7.2 dies in zfs In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> Message-ID: <20091121193643.GA14122@icarus.home.lan> On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > Randy Bush wrote: > > imiho, zfs can not be called production ready if it crashes if you > > do not stand on your left leg, put your right hand in the air, and > > burn some eye of newt. > > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > been marked as production ready. > As far as i know, on FreeBSD 8.0 ZFS is called production ready. > > If you boot your system it probably tell you it is still experimental. > > Try running FreeBSD 7-Stable to get the latest ZFS version which on > FreeBSD is 13 > On 7.2 it is still at 6 (if I remember it right). RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. RELENG_7 and RELENG_8 both, more or less, behave the same way with regards to ZFS. Both panic on kmem exhaustion. No one has answered my question as far as what's needed to stabilise ZFS on either 7.x or 8.x. The people who need to answer the question are those who are familiar with the code. Specifically: Kip Macy, Pawel Jakub Dawidek, and anyone else who knows the internals. Everyone else in the user community is simply guessing + going crazy trying to figure out a solution. As much as I appreciate all the work that has been done to bring ZFS to FreeBSD -- and I do mean that! -- we need answers at this point. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From swhetzel at gmail.com Sat Nov 21 20:32:17 2009 From: swhetzel at gmail.com (Scot Hetzel) Date: Sat Nov 21 20:32:25 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091121193643.GA14122@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> Message-ID: <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> On Sat, Nov 21, 2009 at 1:36 PM, Jeremy Chadwick wrote: > > On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: >> Randy Bush wrote: >> > imiho, zfs can not be called production ready if it crashes if you >> > do not stand on your left leg, put your right hand in the air, and >> > burn some eye of newt. >> >> This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has >> been marked as production ready. >> As far as i know, on FreeBSD 8.0 ZFS is called production ready. >> >> If you boot your system it probably tell you it is still experimental. >> >> Try running FreeBSD 7-Stable to get the latest ZFS version which on >> FreeBSD is 13 >> On 7.2 it is still at 6 (if I remember it right). > > RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > RELENG_8 is still using ZFS v13. > RELENG_7 and RELENG_8 both, more or less, behave the same way with > regards to ZFS. ?Both panic on kmem exhaustion. ?No one has answered my > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > Under RELENG_8/i386, you still need to tune ZFS as mentioned in the ZFS Tuning Guide: http://wiki.freebsd.org/ZFSTuningGuide With RELENG_8/amd64 no tuning is necessary, if the system has at least 2G RAM. Scot From doconnor at gsoft.com.au Sat Nov 21 20:34:13 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat Nov 21 20:34:20 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: <200911210851.04678.doconnor@gsoft.com.au> Message-ID: <200911220704.02065.doconnor@gsoft.com.au> On Sat, 21 Nov 2009, Marius N?nnerich wrote: > >> Maybe. Could you paste kern.geom.confdot, kern.geom.confxml and > >> mount output to pastie.org or the like. > > > > I've attached it.. > > Hmm, I do not see whats wrong here. ZFS already opened the devices > and I see no /dev/gpt/* entries. Maybe there is some bug with > handling the long gptid names. Maybe you try to detach ZFSfrom the > devices, give everything a short gpt label and try to use that. I'd really prefer to use UUID which _does_ exist, ZFS just doesn't like it.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091121/e52b0eaa/attachment.pgp From peterjeremy at acm.org Sat Nov 21 20:57:22 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Sat Nov 21 20:57:29 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091121193643.GA14122@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> Message-ID: <20091121205712.GB35595@server.vk2pj.dyndns.org> On 2009-Nov-21 09:47:56 +0900, Randy Bush wrote: >imiho, zfs can not be called production ready if it crashes if you do >not stand on your left leg, put your right hand in the air, and burn >some eye of newt. FWIW, it's still very brittle on Solaris 10 and the Sun Support response to most issues is "restore from backup". The IMHO, the biggest issue with ZFS itself is lack of recovery tools prior to PSARC 2009/479 (in ZFS v21). On 2009-Nov-21 11:36:43 -0800, Jeremy Chadwick wrote: >RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. Not in my repository. I still have v13 in sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h in last night's RELENG_7, RELENG_8 and -current. >RELENG_7 and RELENG_8 both, more or less, behave the same way with >regards to ZFS. Both panic on kmem exhaustion. No one has answered my >question as far as what's needed to stabilise ZFS on either 7.x or 8.x. My understanding is that the problem is more that the FreeBSD VM system doesn't gracefully handle running low or out of memory. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091121/655fdb07/attachment.pgp From randy at psg.com Sat Nov 21 23:25:44 2009 From: randy at psg.com (Randy Bush) Date: Sat Nov 21 23:25:51 2009 Subject: 7.2 dies in zfs In-Reply-To: <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> Message-ID: >> imiho, zfs can not be called production ready if it crashes if you >> do not stand on your left leg, put your right hand in the air, and >> burn some eye of newt. > ROFL! > As with any open-source project, I suppose it will be ready > when it is ready. At least it hasn't been made the default. yep. i demand a full refund! :) my concern is the innocent admin putting something critical on zfs in 8.0 when it is called stable and production. this isn't linux. randy From randy at psg.com Sat Nov 21 23:34:57 2009 From: randy at psg.com (Randy Bush) Date: Sat Nov 21 23:35:03 2009 Subject: 7.2 dies in zfs In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> Message-ID: >> imiho, zfs can not be called production ready if it crashes if you >> do not stand on your left leg, put your right hand in the air, and >> burn some eye of newt. > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > been marked as production ready. > As far as i know, on FreeBSD 8.0 ZFS is called production ready. whoops! you are correct. my apologies. > Try running FreeBSD 7-Stable to get the latest ZFS version which on > FreeBSD is 13 that is what i am running. RELENG_7 randy From pluknet at gmail.com Sat Nov 21 23:51:27 2009 From: pluknet at gmail.com (pluknet) Date: Sat Nov 21 23:51:34 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091121205712.GB35595@server.vk2pj.dyndns.org> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <20091121205712.GB35595@server.vk2pj.dyndns.org> Message-ID: 2009/11/21 Peter Jeremy : > On 2009-Nov-21 09:47:56 +0900, Randy Bush wrote: >>imiho, zfs can not be called production ready if it crashes if you do >>not stand on your left leg, put your right hand in the air, and burn >>some eye of newt. > > FWIW, it's still very brittle on Solaris 10 and the Sun Support > response to most issues is "restore from backup". ?The IMHO, the > biggest issue with ZFS itself is lack of recovery tools prior to PSARC > 2009/479 (in ZFS v21). > > On 2009-Nov-21 11:36:43 -0800, Jeremy Chadwick wrote: >>RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > > Not in my repository. ?I still have v13 in > sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h in last night's > RELENG_7, RELENG_8 and -current. The good side of things is that there's the ongoing work on v13 -> v22 in perforce. > >>RELENG_7 and RELENG_8 both, more or less, behave the same way with >>regards to ZFS. ?Both panic on kmem exhaustion. ?No one has answered my >>question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > My understanding is that the problem is more that the FreeBSD VM > system doesn't gracefully handle running low or out of memory. AFAIU kmacy works on zfs integration into FreeBSD'ish buf/vm. It'd be nice to read something on that.. -- wbr, pluknet From randy at psg.com Sat Nov 21 23:51:40 2009 From: randy at psg.com (Randy Bush) Date: Sat Nov 21 23:51:46 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091121205712.GB35595@server.vk2pj.dyndns.org> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <20091121205712.GB35595@server.vk2pj.dyndns.org> Message-ID: > My understanding is that the problem is more that the FreeBSD VM > system doesn't gracefully handle running low or out of memory. to me, that's just life in the big city. the problem i think can be solved before this is let loose on the unsuspecting public is that there are really no good tools for tuning. and the wiki page does not cut it. there is not even a table of ram size vs load and good starting parms for the intersection. or "just don't risk real data with less than 2g of ram." randy From freebsd at jdc.parodius.com Sun Nov 22 00:29:29 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Sun Nov 22 00:29:36 2009 Subject: 7.2 dies in zfs In-Reply-To: <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> Message-ID: <20091122002926.GA19628@icarus.home.lan> On Sat, Nov 21, 2009 at 01:59:11PM -0600, Scot Hetzel wrote: > On Sat, Nov 21, 2009 at 1:36 PM, Jeremy Chadwick > wrote: > > > > On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > >> Randy Bush wrote: > >> > imiho, zfs can not be called production ready if it crashes if you > >> > do not stand on your left leg, put your right hand in the air, and > >> > burn some eye of newt. > >> > >> This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > >> been marked as production ready. > >> As far as i know, on FreeBSD 8.0 ZFS is called production ready. > >> > >> If you boot your system it probably tell you it is still experimental. > >> > >> Try running FreeBSD 7-Stable to get the latest ZFS version which on > >> FreeBSD is 13 > >> On 7.2 it is still at 6 (if I remember it right). > > > > RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > > > > RELENG_8 is still using ZFS v13. I meant to type ZFS v13 for RELENG_8. Fingers focused on 8 for some reason... Heh. :-) I'm not going to go on a rant talking about the recurring scenario that keeps happening on the mailing lists -- you know, where Person X says "well, use these loader.conf variables and it's stable", yet Person Y comes back with evidence that it's NOT stable. Everyone's workloads are different, but the panic is the same every time: kmem exhaustion. i386 with KVA_PAGES or amd64 -- happens on both. It's highly dependent upon workload and what the filesystem consists of (many files vs. fewer files but larger in size, etc.) > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > > regards to ZFS. ?Both panic on kmem exhaustion. ?No one has answered my > > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > > Under RELENG_8/i386, you still need to tune ZFS as mentioned in the > ZFS Tuning Guide: > > http://wiki.freebsd.org/ZFSTuningGuide > > With RELENG_8/amd64 no tuning is necessary, if the system has at least 2G RAM. Nope. http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From randy at psg.com Sun Nov 22 00:44:05 2009 From: randy at psg.com (Randy Bush) Date: Sun Nov 22 00:44:12 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091122002926.GA19628@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> <20091122002926.GA19628@icarus.home.lan> Message-ID: > Everyone's workloads are different, but the panic is the same every > time: kmem exhaustion. i386 with KVA_PAGES or amd64 -- happens on both. > It's highly dependent upon workload and what the filesystem consists of > (many files vs. fewer files but larger in size, etc.) these are measurable. at least until it crashes. the suggested memsz script could, instead of giving what to a naive admin are some cute but unhepful numbers, suggest values for loader.conf.local. randy From marco at tols.org Sun Nov 22 01:02:39 2009 From: marco at tols.org (Marco van Tol) Date: Sun Nov 22 01:02:46 2009 Subject: 7.2 dies in zfs In-Reply-To: References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> Message-ID: <20091122002430.GB934@donald.home.tols.org> On Sat, Nov 21, 2009 at 06:16:04PM +0900, Randy Bush wrote: > >> imiho, zfs can not be called production ready if it crashes if you > >> do not stand on your left leg, put your right hand in the air, and > >> burn some eye of newt. > > ROFL! > > As with any open-source project, I suppose it will be ready > > when it is ready. At least it hasn't been made the default. > > yep. i demand a full refund! :) > > my concern is the innocent admin putting something critical on zfs in > 8.0 when it is called stable and production. this isn't linux. Well, to be honest, running something critical on a release candidate is interesting enough as it is right? :-) Just my $0.02 Marco van Tol -- The first step to better times is to imagine them. - www.chinese-fortune-cookie.com From freebsd at jdc.parodius.com Sun Nov 22 01:11:51 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Sun Nov 22 01:13:19 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091122002926.GA19628@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <790a9fff0911211159k14920410g7a76cf6a292f0bae@mail.gmail.com> <20091122002926.GA19628@icarus.home.lan> Message-ID: <20091122011149.GA19922@icarus.home.lan> On Sat, Nov 21, 2009 at 04:29:26PM -0800, Jeremy Chadwick wrote: > On Sat, Nov 21, 2009 at 01:59:11PM -0600, Scot Hetzel wrote: > > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > > > regards to ZFS. ?Both panic on kmem exhaustion. ?No one has answered my > > > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > > > > Under RELENG_8/i386, you still need to tune ZFS as mentioned in the > > ZFS Tuning Guide: > > > > http://wiki.freebsd.org/ZFSTuningGuide > > > > With RELENG_8/amd64 no tuning is necessary, if the system has at least 2G RAM. > > Nope. > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html I'll expand briefly on this because my post mentioned RELENG_7, and the "state" of ZFS in RELENG_7 vs. RELENG_8 vs. HEAD is hard to follow because some of the commits to (what once was) HEAD are actually in RELENG_8 given when HEAD was tagged as RELENG_8. There's a particular situation (with patch for RELENG_8) that has been "making the rounds": http://lists.freebsd.org/pipermail/freebsd-fs/2009-October/006907.html http://lists.freebsd.org/pipermail/freebsd-fs/2009-October/006969.html The discussion is with regards to slow performance as a result of ARC degrading, except numerous posters (including the OP) mention that their box also can "just hang". But this patch seems different than the one which got committed to HEAD (what is CURRENT today); revision 1.25 -- Commit message: Prevent paging pressure from draining arc too much - always drain arc if above arc_c_max - never drain arc if arc is below arc_c_max http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c.diff?r1=1.24;r2=1.25;f=h This commit is not in RELENG_8 nor RELENG_7 (I've confirmed by looking at sources), and of course the patch is "?!?" given the nature of the thread. I've looked at SVN commits to HEAD and Kip has been very, very busy (even today). :-) .....but then there's this commit, which happened ~5 months ago, and made it into HEAD at the time (thus is in RELENG_8; also verified by looking at source): Commit message: Manually export rev 192360 from kmacy http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c.diff?r1=1.19;r2=1.20;f=h ...Which I don't understand technically, but appears to have a direct effect on ARC limiting. So, this is getting very hard to track/follow. Circling back to kmem exhaustion: has there been any official statement on what's actually causing it? Is it ARC overuse (and if so how's that even possible)? Is it ZIL? Is it a combination of things? Is it bugs in the ZFS port (e.g. Solaris VM vs. FreeBSD VM)? Is it all of these things? And ultimately -- how do we work around it? With regards to loader.conf tuning, because this comes up often too: There still has been no official or even semi-official (e.g. Wiki) explanation as far as what should be tuned, and HOW things should be tuned. What are the proper variables to tune this? Tuning on RELENG_7 vs. RELENG_8 also probably differs at this point in time -- or does it? The following loader.conf variables are under scrutiny: vm.kmem_size vm.kmem_size_max vfs.zfs.arc_min vfs.zfs.arc_max vfs.zfs.prefetch_disable vfs.zfs.zil_disable The number of conflicting details on the mailing lists (freebsd-stable, freebsd-current, and freebsd-fs) make it very hard to discern at this point how one is supposed to tune loader.conf to gain stability. For example, I've seen pjd@ mention that one should NOT be touching vm.kmem_size_max, but rather vm.kmem_size -- which I don't understand (and I mean that as in "help me understand", not "I'm questioning the logic"), especially since src/UPDATING states "you probably don't need to adjust either of these". This is why we need people who are familiar with both the ZFS code and the VM to help provide details so that documentation can be updated (I'm referring to the Wiki). If we could get something official from people who are "in the know", that would be awesome. Or maybe this is the wrong list to be discussing it at all, and freebsd-fs is? I don't know any more... It's almost like we need some kind of "ZFS on FreeBSD" newsletter that's sent out weekly documenting all of what's getting changed and what it solves and how it impacts users. Things are totally chaotic right now. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From oliver.pntr at gmail.com Sun Nov 22 01:44:29 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Sun Nov 22 01:44:35 2009 Subject: MFC of r198284 to 7-STABLE Message-ID: <6101e8c40911211744y3ec455a2l441361171d9a004b@mail.gmail.com> commit 4a6ea694eaad85c9ff99668ba7427c00cea3e990 Author: kib Date: Tue Oct 20 13:34:41 2009 +0000 MFC r197934: Map PIE binaries at non-zero base address. MFC r198202: Honour non-zero mapbase for PIE binaries. Inform interpreter-less PIE binary about its relocbase. Approved by: re (kensmith) git-svn-id: svn://svn.freebsd.org/base/stable/8@198284 ccf9f872-aa2e-dd11-9fc8-001c23d0 From exemys at exemys.com Sun Nov 22 02:44:13 2009 From: exemys at exemys.com (Exemys) Date: Sun Nov 22 02:44:26 2009 Subject: Pulse Meter with Cellular communication Message-ID: <145b6ddbb47618a8ff694dd543543ede@www.hostmailing.com> This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From gjin at ubicom.com Sun Nov 22 03:46:25 2009 From: gjin at ubicom.com (Guojun Jin) Date: Sun Nov 22 03:46:34 2009 Subject: 8.0-RC USB problem -- how to recover a damaged USB stick References: <200911181213.34112.hselasky@c2i.net> Message-ID: It seems this is more serious problem in 8.0, and I hope it could be resolved before a formal release. I can help to diagnose this if people need more information (this is destructive). I have picked a USB stick (DataTraveler 2GB), that has two partitions s0 for DOS and s1 for FreeBSD. Both USB hard drive and the USB stick have worked under FreeBSD 6.2, 6.3, 6.4 and 7.2 for a few years without any problem. Plugged USB stick in 8.0-RC and mounted it on /mnt; then untar a file, tarred one day ago from FreeBSD 6.3 machine onto stick,to a IDE drive then tar it back to the USB stick. During tar writting from IDE to USB stick, did "ls /mnt", and "tar" paused and "ls" hangs. A couple of minutes later, ls comes back, but tar still pauses. Hit ^C on tar process around 14:30, it took another minutes to stop the process. Tried tar again, and system disallowed to write on the USB stick. "ls" shows all file still there (probably cached inods). Went out for a few hours, and came back found /var/log/message are flooded with following message: -rw-r--r-- 1 root wheel 167181 Nov 21 19:02 messages -rw-r--r-- 1 root wheel 7390 Nov 21 18:00 messages.0.bz2 -rw-r--r-- 1 root wheel 7509 Nov 21 17:00 messages.1.bz2 -rw-r--r-- 1 root wheel 9365 Nov 21 16:00 messages.2.bz2 -rw-r--r-- 1 root wheel 20598 Nov 21 15:00 messages.3.bz2 Nov 21 18:00:00 wolf newsyslog[2635]: logfile turned over due to size>384K Nov 21 18:00:27 wolf kernel: g_vfs_done():da0s2[WRITE(offset=625688576, length=1 31072)]error = 5 Nov 21 18:00:27 wolf kernel: g_vfs_done():da0s2[WRITE(offset=625819648, length=1 31072)]error = 5 ..... Nov 21 18:19:03 wolf kernel: g_vfs_done():da0s2[WRITE(offset=524451840, length=1 6384)]error = 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=5586944, length=204 8)]error = 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=65536, length=2048) ]error = 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=114688, length=1638 4)]error = 5 Nov 21 18:20:05 wolf kernel: g_vfs_done():da0s2[WRITE(offset=349700096, length=1 and has to reboot the system, and reboot was not able to umount everything (boot up message): Nov 21 18:24:03 wolf kernel: da0: Removable Dir ect Access SCSI-2 device Nov 21 18:24:03 wolf kernel: da0: 40.000MB/s transfers Nov 21 18:24:03 wolf kernel: da0: 1947MB (3987456 512 byte sectors: 255H 63S/T 2 48C) Nov 21 18:24:03 wolf kernel: WARNING: / was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /data was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /home was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /tmp was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /usr was not properly dismounted ... # mount /dev/da0s2 /mnt mount: /dev/da0s2 : Operation not permitted The USB stick cannot be mount under any FreeBSD OS now, and everything on the drive has lost. Does anyone know if it is possible to revocer such damaged USB stick? -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/18/2009 3:13 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; freebsd-stable@freebsd.org; questions@freebsd.org Subject: Re: 8.0-RC3 USB lock up on mounting two partitions from one USB drive Hi, I'm not sure if this is an USB issue or not. If you get READ/WRITE errors and the drive simply dies then it might be the case. Else it is a system issue. There are quirks for mass storage which you can add to sys/dev/usb/storage/umass.c . --HPS On Wednesday 18 November 2009 08:33:07 Guojun Jin wrote: > Did newfs on those partition and made things worsen -- restore completely > fails: (I had experienced another similar problem on an IDE, which works > well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD 6.4. > > Is something new in 8.0 making disk partition schema changed? > > g_vfs_done():da0s3d[READ(offset=98304, length=16384)]error = 6 > g_vfs_done():da0s3d[WRITE(offset=192806912, length=16384)]error = 6 > fopen: Device not configured > cannot create save file ./restoresymtable for symbol table > abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status == > 0xa, scs i status == 0x0 > (da0:umass-sim0:0:0:0): removing device entry > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) > Device da0s3d went missing before all of the data could be written to it; > expect data loss. > > 99 23:19 sysinstall > 100 23:20 newfs /dev/da0s3d > 101 23:20 newfs /dev/da0s3e > 102 23:21 mount /dev/da0s3d /mnt > 103 23:21 cd /mnt > 104 23:21 dump -0f - /home | restore -rf - > 105 23:27 history 15 > > > > -----Original Message----- > From: Guojun Jin > Sent: Tue 11/17/2009 11:05 PM > To: freebsd-stable@freebsd.org > Cc: questions@freebsd.org; freebsd-usb@freebsd.org > Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive > > When mounting two partitions from a USB dirve, it can cause the drive > access lock up for a long time. Details: > > Terminal 1 -- > term1# mount /dev/da0s3d /mnt > term1# cd /mnt ; rm -fr * > > when rm starts, go to terminal 2 and do: > > term2# mount /dev/da0s3e /dist ### this will hanging for a long time and > USB hard drive activity light is off. After more than 1-2 minutes, mount > returns, and the drive activity light is blinking, thus removing is going > on. > > term2# ls /dist ### this will cause dUSB dirve hanging again -- no > avtivity. Similarly, ls will finish in a couple of miniutes or longer, the > rm command continues; but for a while, the drive activity will stop again. > > Reboot machine, repeat the above steps, and result will be the same. Reboot > machine again, and just mount one partition, then doing "rm -rf *" without > involve the second partition, rm will finish quickly. > > Has anyone obseved this behave on 8.0-RC? > > -Jin From gjin at ubicom.com Sun Nov 22 04:45:34 2009 From: gjin at ubicom.com (Guojun Jin) Date: Sun Nov 22 04:45:48 2009 Subject: 8.0-RC USB/FS problem References: <200911181213.34112.hselasky@c2i.net> Message-ID: Tried on the USB hard drive: Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. Was happy because successfully did dump/restore on s3d, and thought it just partition format issue; but system crashed during dump/restore on s3e, and partition lost the file system type. wolf# mount /dev/da0s3e /mnt WARNING: /mnt was not properly dismounted /mnt: mount pending error: blocks 35968 files 0 wolf# fsck da0s3e fsck: Could not determine filesystem type wolf# bsdlabel da0s3 # /dev/da0s3: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 175735035 0 unused 0 0 # "raw" part, don't edi t d: 18874368 0 4.2BSD 0 0 0 e: 156860667 18874368 4.2BSD 0 0 0 Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick to get file system clean up. All data got back now. The machine has run with FreeBSD 6.1 all the way to 7.2 without such problem. How can we determine what could go wrong in 8.0? FS or USB. By the way, IDE to IDE dump/restore seems not having such problem at this point, although one of IDE drive experienced partition recognizing problem, which went away after deleting slices and recreating slices. -----Original Message----- From: Guojun Jin Sent: Sat 11/21/2009 7:40 PM To: Hans Petter Selasky; freebsd-usb@freebsd.org Cc: freebsd-stable@freebsd.org; questions@freebsd.org Subject: 8.0-RC USB problem -- how to recover a damaged USB stick It seems this is more serious problem in 8.0, and I hope it could be resolved before a formal release. I can help to diagnose this if people need more information (this is destructive). I have picked a USB stick (DataTraveler 2GB), that has two partitions s0 for DOS and s1 for FreeBSD. Both USB hard drive and the USB stick have worked under FreeBSD 6.2, 6.3, 6.4 and 7.2 for a few years without any problem. Plugged USB stick in 8.0-RC and mounted it on /mnt; then untar a file, tarred one day ago from FreeBSD 6.3 machine onto stick,to a IDE drive then tar it back to the USB stick. During tar writting from IDE to USB stick, did "ls /mnt", and "tar" paused and "ls" hangs. A couple of minutes later, ls comes back, but tar still pauses. Hit ^C on tar process around 14:30, it took another minutes to stop the process. Tried tar again, and system disallowed to write on the USB stick. "ls" shows all file still there (probably cached inods). Went out for a few hours, and came back found /var/log/message are flooded with following message: -rw-r--r-- 1 root wheel 167181 Nov 21 19:02 messages -rw-r--r-- 1 root wheel 7390 Nov 21 18:00 messages.0.bz2 -rw-r--r-- 1 root wheel 7509 Nov 21 17:00 messages.1.bz2 -rw-r--r-- 1 root wheel 9365 Nov 21 16:00 messages.2.bz2 -rw-r--r-- 1 root wheel 20598 Nov 21 15:00 messages.3.bz2 Nov 21 18:00:00 wolf newsyslog[2635]: logfile turned over due to size>384K Nov 21 18:00:27 wolf kernel: g_vfs_done():da0s2[WRITE(offset=625688576, length=1 31072)]error = 5 Nov 21 18:00:27 wolf kernel: g_vfs_done():da0s2[WRITE(offset=625819648, length=1 31072)]error = 5 ..... Nov 21 18:19:03 wolf kernel: g_vfs_done():da0s2[WRITE(offset=524451840, length=1 6384)]error = 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=5586944, length=204 8)]error = 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=65536, length=2048) ]error = 5 Nov 21 18:19:33 wolf kernel: g_vfs_done():da0s2[WRITE(offset=114688, length=1638 4)]error = 5 Nov 21 18:20:05 wolf kernel: g_vfs_done():da0s2[WRITE(offset=349700096, length=1 and has to reboot the system, and reboot was not able to umount everything (boot up message): Nov 21 18:24:03 wolf kernel: da0: Removable Dir ect Access SCSI-2 device Nov 21 18:24:03 wolf kernel: da0: 40.000MB/s transfers Nov 21 18:24:03 wolf kernel: da0: 1947MB (3987456 512 byte sectors: 255H 63S/T 2 48C) Nov 21 18:24:03 wolf kernel: WARNING: / was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /data was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /home was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /tmp was not properly dismounted Nov 21 18:24:03 wolf kernel: WARNING: /usr was not properly dismounted ... # mount /dev/da0s2 /mnt mount: /dev/da0s2 : Operation not permitted The USB stick cannot be mount under any FreeBSD OS now, and everything on the drive has lost. Does anyone know if it is possible to revocer such damaged USB stick? -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/18/2009 3:13 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; freebsd-stable@freebsd.org; questions@freebsd.org Subject: Re: 8.0-RC3 USB lock up on mounting two partitions from one USB drive Hi, I'm not sure if this is an USB issue or not. If you get READ/WRITE errors and the drive simply dies then it might be the case. Else it is a system issue. There are quirks for mass storage which you can add to sys/dev/usb/storage/umass.c . --HPS On Wednesday 18 November 2009 08:33:07 Guojun Jin wrote: > Did newfs on those partition and made things worsen -- restore completely > fails: (I had experienced another similar problem on an IDE, which works > well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD 6.4. > > Is something new in 8.0 making disk partition schema changed? > > g_vfs_done():da0s3d[READ(offset=98304, length=16384)]error = 6 > g_vfs_done():da0s3d[WRITE(offset=192806912, length=16384)]error = 6 > fopen: Device not configured > cannot create save file ./restoresymtable for symbol table > abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status == > 0xa, scs i status == 0x0 > (da0:umass-sim0:0:0:0): removing device entry > ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) > Device da0s3d went missing before all of the data could be written to it; > expect data loss. > > 99 23:19 sysinstall > 100 23:20 newfs /dev/da0s3d > 101 23:20 newfs /dev/da0s3e > 102 23:21 mount /dev/da0s3d /mnt > 103 23:21 cd /mnt > 104 23:21 dump -0f - /home | restore -rf - > 105 23:27 history 15 > > > > -----Original Message----- > From: Guojun Jin > Sent: Tue 11/17/2009 11:05 PM > To: freebsd-stable@freebsd.org > Cc: questions@freebsd.org; freebsd-usb@freebsd.org > Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive > > When mounting two partitions from a USB dirve, it can cause the drive > access lock up for a long time. Details: > > Terminal 1 -- > term1# mount /dev/da0s3d /mnt > term1# cd /mnt ; rm -fr * > > when rm starts, go to terminal 2 and do: > > term2# mount /dev/da0s3e /dist ### this will hanging for a long time and > USB hard drive activity light is off. After more than 1-2 minutes, mount > returns, and the drive activity light is blinking, thus removing is going > on. > > term2# ls /dist ### this will cause dUSB dirve hanging again -- no > avtivity. Similarly, ls will finish in a couple of miniutes or longer, the > rm command continues; but for a while, the drive activity will stop again. > > Reboot machine, repeat the above steps, and result will be the same. Reboot > machine again, and just mount one partition, then doing "rm -rf *" without > involve the second partition, rm will finish quickly. > > Has anyone obseved this behave on 8.0-RC? > > -Jin From mcdouga9 at egr.msu.edu Sun Nov 22 05:20:33 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sun Nov 22 05:20:40 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091121193643.GA14122@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> Message-ID: <20091122052030.GL1213@egr.msu.edu> On Sat, Nov 21, 2009 at 11:36:43AM -0800, Jeremy Chadwick wrote: On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > Randy Bush wrote: > > imiho, zfs can not be called production ready if it crashes if you > > do not stand on your left leg, put your right hand in the air, and > > burn some eye of newt. > > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > been marked as production ready. > As far as i know, on FreeBSD 8.0 ZFS is called production ready. > > If you boot your system it probably tell you it is still experimental. > > Try running FreeBSD 7-Stable to get the latest ZFS version which on > FreeBSD is 13 > On 7.2 it is still at 6 (if I remember it right). RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. RELENG_7 and RELENG_8 both, more or less, behave the same way with regards to ZFS. Both panic on kmem exhaustion. No one has answered my question as far as what's needed to stabilise ZFS on either 7.x or 8.x. I have a stable public ftp/http/rsync/cvsupd mirror that runs ZFS v13. It has been stable since mid may. I have not had a kmem panic on any of my ZFS systems for a long time, its a matter of making sure there is enough kmem at boot (not depending on kmem_size_max) and that it is big enough that fragmentation does not cause a premature allocation failure due to lack of large-enough contiguous chunk. This requires the platform to support a kmem size that is "big enough"... i386 can barely muster 1.6G and sometimes that might not be enough. I'm pretty sure all of my currently existing ZFS systems are amd64 where the kmem can now be huge. On the busy fileserver with 20 gigs of ram running FreeBSD 8.0-RC2 #21: Tue Oct 27 21:45:41 EDT 2009, I currently have: vfs.zfs.arc_max=16384M vfs.zfs.arc_min=4096M vm.kmem_size=18G The arc settings here are to try to encourage it to favor the arc cache instead of whatever else Inactive memory in 'top' contains. On other systems that are hit less hard, I simply set: vm.kmem_size="20G" I even do this on systems with much less ram, it doesn't seem to matter except it works, this is on an amd64 with only 8G. Most of my ZFS systems are 7.2-stable, some are 8.0-something. Anything with v13 is much better than v6, but 8.0 has additional fixes that have not been backported to 7 yet. I don't consider the additional fixes in 8 required for my uses yet, although I'm planning on moving forward eventually. I would consider 2G kmem a realistic minimum on a system that will see some serious disk IO (regardless of how much ram the system actually contains, as long as the kmem size can be set that big and the system not blow chunks). Hope this personal experience helps. The people who need to answer the question are those who are familiar with the code. Specifically: Kip Macy, Pawel Jakub Dawidek, and anyone else who knows the internals. Everyone else in the user community is simply guessing + going crazy trying to figure out a solution. As much as I appreciate all the work that has been done to bring ZFS to FreeBSD -- and I do mean that! -- we need answers at this point. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From spork at bway.net Sun Nov 22 07:31:35 2009 From: spork at bway.net (Charles Sprickman) Date: Sun Nov 22 07:31:42 2009 Subject: panic in 7.2 (ffs_alloc.c?) Message-ID: Howdy, I'm not expert at getting info out of a dump, but I'll do my best to provide some information. This is a Dell PE2970 w/PERC6/i RAID running FreeBSD 7.2/amd64. Brand new box, has been doing very light work for about two weeks. Last night I started a very long mstone run on a jailed mail server and found that quite a way into this burn-in, the box paniced. I was going to put it in service Monday (after punishing it all weekend). Looking for some input on what the root cause is and whether going to a -stable snapshot might be worthwhile. I can tell you there was a good deal of disk activity at the time in the jail - mstone was simulating 100 POP and SMTP clients hitting the machine at once. This is qmail+courier. So messages are coming in, hitting the queue, hitting a user's maildir, getting read and deleted via the POP "client" over and over again. I do see lots of "ffs_*" stuff in the backtrace, which is a little scary. Here's my stab at a kgdb session (also @ pastie for easier reading: http://pastie.org/709671): [root@bigmail /usr/obj/usr/src/sys/BWAY7-64]# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x12d4b9f5c fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8050382e stack pointer = 0x10:0xffffffff281a75b0 frame pointer = 0x10:0xffffff000455f800 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6324 (vdelivermail) trap number = 12 panic: page fault cpuid = 0 Uptime: 12d0h32m3s Physical memory: 6130 MB Dumping 725 MB: 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); #3 0xffffffff8034cba2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff80574823 in trap_fatal (frame=0xffffff00046c8000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0xffffffff80574bf5 in trap_pfault (frame=0xffffffff281a7500, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0xffffffff80575534 in trap (frame=0xffffffff281a7500) at /usr/src/sys/amd64/amd64/trap.c:444 #7 0xffffffff8055969e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0xffffffff8050382e in ffs_realloccg (ip=0xffffff00267f75c0, lbprev=0, bprev=6288224785898156086, bpref=593305256, osize=0, nsize=2048, flags=33619968, cred=0xffffff00927fe800, bpp=0xffffffff281a7800) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1349 #9 0xffffffff80506e8e in ffs_balloc_ufs2 (vp=0xffffff0027a64dc8, startoffset=Variable "startoffset" is not available. ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:692 #10 0xffffffff805223e5 in ffs_write (ap=0xffffffff281a7a10) at /usr/src/sys/ufs/ffs/ffs_vnops.c:724 #11 0xffffffff805a0645 in VOP_WRITE_APV (vop=0xffffffff80793d20, a=0xffffffff281a7a10) at vnode_if.c:691 #12 0xffffffff803dd731 in vn_write (fp=0xffffff001027cd00, uio=0xffffffff281a7b00, active_cred=Variable "active_cred" is not available. ) at vnode_if.h:373 #13 0xffffffff80388768 in dofilewrite (td=0xffffff00046c8000, fd=5, fp=0xffffff001027cd00, auio=dwarf2_read_address: Corrupted DWARF expression. ) at file.h:257 #14 0xffffffff80388a6e in kern_writev (td=0xffffff00046c8000, fd=5, auio=0xffffffff281a7b00) at /usr/src/sys/kern/sys_generic.c:402 #15 0xffffffff80388aec in write (td=0x800, uap=0x12d4b9f50) at /usr/src/sys/kern/sys_generic.c:318 #16 0xffffffff80596a66 in ia32_syscall (frame=0xffffffff281a7c80) at /usr/src/sys/amd64/ia32/ia32_syscall.c:182 #17 0xffffffff80559ad0 in Xint0x80_syscall () at ia32_exception.S:65 #18 0x0000000028167928 in ?? () Previous frame inner to this frame (corrupt stack?) Full dmesg, verbose boot and kernel config at pastie as well. Actually no verbose boot... I rebooted the box after setting verbose boot with "nextboot" and it didn't come back. Hrmph. No remote console, so I don't know what's up, perhaps waiting on some manual fsck action. Thanks, Charles From svein-listmail at stillbilde.net Sun Nov 22 09:00:08 2009 From: svein-listmail at stillbilde.net (Svein Skogen (listmail account)) Date: Sun Nov 22 09:00:15 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091122052030.GL1213@egr.msu.edu> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <20091122052030.GL1213@egr.msu.edu> Message-ID: <4B08FD93.4070409@stillbilde.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam McDougall wrote: > On Sat, Nov 21, 2009 at 11:36:43AM -0800, Jeremy Chadwick wrote: > > > On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > > Randy Bush wrote: > > > imiho, zfs can not be called production ready if it crashes if you > > > do not stand on your left leg, put your right hand in the air, and > > > burn some eye of newt. > > > > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > > been marked as production ready. > > As far as i know, on FreeBSD 8.0 ZFS is called production ready. > > > > If you boot your system it probably tell you it is still experimental. > > > > Try running FreeBSD 7-Stable to get the latest ZFS version which on > > FreeBSD is 13 > > On 7.2 it is still at 6 (if I remember it right). > > RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > regards to ZFS. Both panic on kmem exhaustion. No one has answered my > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > I have a stable public ftp/http/rsync/cvsupd mirror that runs ZFS v13. > It has been stable since mid may. I have not had a kmem panic on any > of my ZFS systems for a long time, its a matter of making sure there is > enough kmem at boot (not depending on kmem_size_max) and that it is big enough > that fragmentation does not cause a premature allocation failure due to lack > of large-enough contiguous chunk. This requires the platform to support a > kmem size that is "big enough"... i386 can barely muster 1.6G and sometimes > that might not be enough. I'm pretty sure all of my currently existing ZFS > systems are amd64 where the kmem can now be huge. On the busy fileserver with > 20 gigs of ram running FreeBSD 8.0-RC2 #21: Tue Oct 27 21:45:41 EDT 2009, > I currently have: > vfs.zfs.arc_max=16384M > vfs.zfs.arc_min=4096M > vm.kmem_size=18G > The arc settings here are to try to encourage it to favor the arc cache > instead of whatever else Inactive memory in 'top' contains. Very interesting. For my iscsi backend (running istgt from ports), I had to change the arc_max below 128M to stop iSCSI initiators generating timeouts when the cache flushed. (This is on a system with a megaraid 8308ELP handling the disk back end, with the disks in two RAID5 arrays of four disks each, zpooled as one big pool). When I had more than 128M arc_max, zfs on regular times ate all available resources to flush to disk, leaving the istgt waiting, and iSCSI initiators timed out and had to reconnect. The iSCSI initiators are the built-in software initator in VMWare ESX 4i. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg ?stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksI/ZMACgkQODUnwSLUlKRr6gCfeq5dybIfp5RLOzjL04guLV25 +qgAn04SjnGG3lBRExQaMjxyKcd9Jcct =ubYi -----END PGP SIGNATURE----- From hselasky at c2i.net Sun Nov 22 09:31:44 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Nov 22 09:31:57 2009 Subject: 8.0-RC USB problem -- how to recover a damaged USB stick In-Reply-To: References: <200911181213.34112.hselasky@c2i.net> Message-ID: <200911221033.17251.hselasky@c2i.net> On Sunday 22 November 2009 04:40:27 Guojun Jin wrote: > Does anyone know if it is possible to revocer such damaged USB stick? Hi, There are several recovery tools in /usr/ports for this kind of task. For example photorec . --HPS From hselasky at c2i.net Sun Nov 22 09:45:47 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Nov 22 09:46:13 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: References: Message-ID: <200911221047.20362.hselasky@c2i.net> On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it just > partition format issue; but system crashed during dump/restore on s3e, and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, is to blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a problem. On FreeBSD we just try a software reset via the control endpoint. I guess that it is a device problem you are seeing. The USB stack in FreeBSD is faster than the old one, and maybe the faster queueing of mass storage requests trigger some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=-1 --HPS From freebsd at abv.bg Sun Nov 22 15:13:00 2009 From: freebsd at abv.bg (Mario Pavlov) Date: Sun Nov 22 15:13:08 2009 Subject: BIOS resource allocation and FreeBSD ACPI Message-ID: <24772986.196751.1258902794788.JavaMail.apache@mail53.abv.bg> Hi, I see this problem over and over again... some time ago I created this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/135070 and I just saw it has been duplicated: http://www.freebsd.org/cgi/query-pr.cgi?pr=140751 maybe the later one should be closed as a duplicate... anyway I think I saw this problem reported for more than 10 different laptops in the lists and the forums...maybe it's time someone to fix this issue ... I'm willing to donate money if someone can take and fix this (yes, I'm serious, I think it's worth it) regards, mgp ----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg! http://www.vesti.bg From mcdouga9 at egr.msu.edu Sun Nov 22 16:51:27 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sun Nov 22 16:51:34 2009 Subject: 7.2 dies in zfs In-Reply-To: <4B08FD93.4070409@stillbilde.net> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <20091121193643.GA14122@icarus.home.lan> <20091122052030.GL1213@egr.msu.edu> <4B08FD93.4070409@stillbilde.net> Message-ID: <20091122165125.GN1213@egr.msu.edu> On Sun, Nov 22, 2009 at 10:00:03AM +0100, Svein Skogen (listmail account) wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam McDougall wrote: > On Sat, Nov 21, 2009 at 11:36:43AM -0800, Jeremy Chadwick wrote: > > > On Sat, Nov 21, 2009 at 08:07:40PM +0100, Johan Hendriks wrote: > > Randy Bush wrote: > > > imiho, zfs can not be called production ready if it crashes if you > > > do not stand on your left leg, put your right hand in the air, and > > > burn some eye of newt. > > > > This is not a rant, but where do you read that on FreeBSD 7.2 ZFS has > > been marked as production ready. > > As far as i know, on FreeBSD 8.0 ZFS is called production ready. > > > > If you boot your system it probably tell you it is still experimental. > > > > Try running FreeBSD 7-Stable to get the latest ZFS version which on > > FreeBSD is 13 > > On 7.2 it is still at 6 (if I remember it right). > > RELENG_7 uses ZFS v13, RELENG_8 uses ZFS v18. > > RELENG_7 and RELENG_8 both, more or less, behave the same way with > regards to ZFS. Both panic on kmem exhaustion. No one has answered my > question as far as what's needed to stabilise ZFS on either 7.x or 8.x. > > I have a stable public ftp/http/rsync/cvsupd mirror that runs ZFS v13. > It has been stable since mid may. I have not had a kmem panic on any > of my ZFS systems for a long time, its a matter of making sure there is > enough kmem at boot (not depending on kmem_size_max) and that it is big enough > that fragmentation does not cause a premature allocation failure due to lack > of large-enough contiguous chunk. This requires the platform to support a > kmem size that is "big enough"... i386 can barely muster 1.6G and sometimes > that might not be enough. I'm pretty sure all of my currently existing ZFS > systems are amd64 where the kmem can now be huge. On the busy fileserver with > 20 gigs of ram running FreeBSD 8.0-RC2 #21: Tue Oct 27 21:45:41 EDT 2009, > I currently have: > vfs.zfs.arc_max=16384M > vfs.zfs.arc_min=4096M > vm.kmem_size=18G > The arc settings here are to try to encourage it to favor the arc cache > instead of whatever else Inactive memory in 'top' contains. Very interesting. For my iscsi backend (running istgt from ports), I had to change the arc_max below 128M to stop iSCSI initiators generating timeouts when the cache flushed. (This is on a system with a megaraid 8308ELP handling the disk back end, with the disks in two RAID5 arrays of four disks each, zpooled as one big pool). When I had more than 128M arc_max, zfs on regular times ate all available resources to flush to disk, leaving the istgt waiting, and iSCSI initiators timed out and had to reconnect. The iSCSI initiators are the built-in software initator in VMWare ESX 4i. //Svein I could understand that happening. I've seen situations in the past where my kmem was smaller than I wanted it to be, and within a few days the overall ZFS disk IO would become incredibly slow because it was trying to flush out the ARC way too often because of external intense memory pressure on the ARC. Assuming you have a large amount of ram, I wonder if setting kmem_size, arc_min and arc_max sufficiently large and using modern code would help as long as you made sure other processes on the machine don't squeeze down Wired memory in top too much. In such a situation, I would expect it to operate fine while the ARC has enough kmem to expand as much as it wants to, and it might either hit a wall later or perhaps given enough ARC the reclamation might be tolerable. Or, if 128M ARC is good enough for you, leave it :) From bz at FreeBSD.org Sun Nov 22 22:10:11 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sun Nov 22 22:10:23 2009 Subject: HEADS UP: removal of PECOFF support in RELENG_[67] Message-ID: <20091122215953.L37440@maildrop.int.zabbadoz.net> Hi, I'd like to give you a heads up that I intend to also remove PECOFF support from the stable/7 and stable/6 branches. PECOFF support is non-working and unmaintained in those FreeBSD releases and has lately still seen public security problems. PECOFF support is already gone in the upcoming 8.0 RELEASE or the 9-CURRENT development branch. Should no valid complaints come up saying that someone needs (and actively uses *cough* PECOFF support on FreeBSD it'll be removed earliest Novemeber 29th 2009 00:00 UTC (in about one week). /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From mi+thun at aldan.algebra.com Mon Nov 23 00:51:54 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Mon Nov 23 00:52:07 2009 Subject: openoffice stuck in _umtx_op Message-ID: <4B09D7BE.20602@aldan.algebra.com> Hello! I'm trying to start OOo, and it hangs at start-up -- after popping up its banner page. ktrace shows the following, slowly repeating, sequence of events: [...] 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fffffbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fffffbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fffffbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fffffbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fffffbfeef0) [...] what's happening? `ipcs -a' does not show anything extraordinary and there is nothing in syslog either... The machine is running 7.2-STABLE/amd64 (as of Oct 25). Any ideas? Thanks! -mi From zbeeble at gmail.com Mon Nov 23 02:09:03 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon Nov 23 02:09:10 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <20091114024438.GA93630@icarus.home.lan> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> Message-ID: <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick wrote: > > > This 1950 may predate that a bit, but I'm not sure how to nail it down > > exactly, other than by it's hardware components. Anyways, 7.0 does the > same > > thing --- still wedged. > > I haven't seen anyone recommend this as a test method yet -- disabling > fdc prior to the kernel booting via the loader prompt: > > - Press 6 at the menu, > - At the loader prompt, type: > > set hint.fdc.0.disabled="1" > boot -v (or without -v; your choice) > > You shouldn't need to set hint.fd.0.disabled="1", since fd0 would > normally bind to fdc0; disable the latter and you disable the lesser. > > The intention here is to rule out the device attachment failures from > fdc as the source of the deadlock. > Entertainingly, it does not. Aparently that hint doesn't stop the code from trying to attach fdc0 when acpi says so. I suppose I need to know the console command to disable acpi and fdc. but it still wedges at "device_attach: fdc0 attach returned 6" with the above. From gjin at ubicom.com Mon Nov 23 04:12:00 2009 From: gjin at ubicom.com (Guojun Jin) Date: Mon Nov 23 04:12:08 2009 Subject: 8.0-RC USB/FS problem References: <200911221047.20362.hselasky@c2i.net> Message-ID: >From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at different USB access phase at each time. dd if=/dev/zero of=/dev/da0 count=1000 bs=4k sysinstall partition slice 1 (da0s1) 18GB ID=12 slice 2 (da0s2) 10-15GB Id=165 slice 3 (da0s3) rest ID=165 W ---> OK label da0s3d 9GB /mnt da0s3e rest /dist W ---> da0s3e ---- device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r----- 1 root operator 0, 97 Nov 22 11:23 /dev/da0 crw-r----- 1 root operator 0, 98 Nov 22 11:23 /dev/da0s1 crw-r----- 1 root operator 0, 99 Nov 22 11:23 /dev/da0s2 crw-r----- 1 root operator 0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r----- 1 root operator 0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=-1) After system reboot, and repeated above processes, the da0s3e was mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 8.0-RELEASE to see if anything will improve. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it just > partition format issue; but system crashed during dump/restore on s3e, and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, is to blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a problem. On FreeBSD we just try a software reset via the control endpoint. I guess that it is a device problem you are seeing. The USB stack in FreeBSD is faster than the old one, and maybe the faster queueing of mass storage requests trigger some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=-1 --HPS From seklecki at noc.cfi.pgh.pa.us Mon Nov 23 04:16:12 2009 From: seklecki at noc.cfi.pgh.pa.us (Brian Seklecki) Date: Mon Nov 23 04:16:19 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911121356j608b41dct6ad7c1109b5d0438@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <6201873e0911121327x8b5a16k86c5018582785396@mail.gmail.com> <5f67a8c40911121355m5f115c93j7d1908336591fe31@mail.gmail.com> <5f67a8c40911121356j608b41dct6ad7c1109b5d0438@mail.gmail.com> Message-ID: <1258948165.27241.8.camel@localhost.localdomain> On Thu, 2009-11-12 at 16:56 -0500, Zaphod Beeblebrox wrote: > > I've now verified that 8.0-RC3 does the same thing, BTW. > > Anyways... no. There is no floppy option in the BIOS. It's not in Dell BIOS absolutely sucks. You get what you pay for. We have 25+ 9th gen systems. Revision 1, with the older HT Xeons, are all lemons. The only thing that runs stable on them in ESXi R3 of the 1950 with the PERC6 and DRAC5 works fine on 6.3/amd64, 7.2, etc. ~BAS > any of the sub-menus (which is how Dell's BIOS is organized). I'm > also not-so-sure that the floppy is where it's stopping because the > non-ACPI boot doesn't From zbeeble at gmail.com Mon Nov 23 04:47:56 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon Nov 23 04:48:02 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> Message-ID: <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> On Sun, Nov 22, 2009 at 9:09 PM, Zaphod Beeblebrox wrote: > > > On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick > wrote: > >> >> > This 1950 may predate that a bit, but I'm not sure how to nail it down >> > exactly, other than by it's hardware components. Anyways, 7.0 does the >> same >> > thing --- still wedged. >> >> I haven't seen anyone recommend this as a test method yet -- disabling >> fdc prior to the kernel booting via the loader prompt: >> >> - Press 6 at the menu, >> - At the loader prompt, type: >> >> set hint.fdc.0.disabled="1" >> boot -v (or without -v; your choice) >> >> You shouldn't need to set hint.fd.0.disabled="1", since fd0 would >> normally bind to fdc0; disable the latter and you disable the lesser. >> >> The intention here is to rule out the device attachment failures from >> fdc as the source of the deadlock. >> > > Entertainingly, it does not. Aparently that hint doesn't stop the code > from trying to attach fdc0 when acpi says so. I suppose I need to know the > console command to disable acpi and fdc. > > but it still wedges at "device_attach: fdc0 attach returned 6" with the > above. > > OK. With both floppy and acpi disabled, it dies calling "start_init" several times, the last being /stand/sysinstal (which should work). I don't see it "starting" the other CPUs. It hangs hard... no keyboard working (ie: no caps lock). From borjam at sarenet.es Mon Nov 23 08:41:46 2009 From: borjam at sarenet.es (Borja Marcos) Date: Mon Nov 23 08:41:59 2009 Subject: 7.2 dies in zfs In-Reply-To: References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> Message-ID: <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: > >> Try running FreeBSD 7-Stable to get the latest ZFS version which on >> FreeBSD is 13 > > that is what i am running. RELENG_7 I've been following ZFS on FreeBSD long ago, and it really seems to be stable on 8.0/amd64. Even Sun Microsystems say that ZFS is better used on a 64 bit system, they don't recommend it on the 32 bit version of Solaris. That said, there's still an outstanding bug, I managed to deadlock it but the condition is easy to avoid. Borja. From freebsd at jdc.parodius.com Mon Nov 23 09:01:25 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Mon Nov 23 09:01:32 2009 Subject: 7.2 dies in zfs In-Reply-To: <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> Message-ID: <20091123090121.GA59823@icarus.home.lan> On Mon, Nov 23, 2009 at 09:41:43AM +0100, Borja Marcos wrote: > On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: > > > >> Try running FreeBSD 7-Stable to get the latest ZFS version which on > >> FreeBSD is 13 > > > > that is what i am running. RELENG_7 > > I've been following ZFS on FreeBSD long ago, and it really seems to be stable on 8.0/amd64. > Even Sun Microsystems say that ZFS is better used on a 64 bit system, they don't recommend it > on the 32 bit version of Solaris. > > That said, there's still an outstanding bug, I managed to deadlock it but the condition is easy to avoid. Please provide details of this deadlock (PR, kernel output, scenario details, etc.), and details of how to avoid it. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From borjam at sarenet.es Mon Nov 23 09:47:20 2009 From: borjam at sarenet.es (Borja Marcos) Date: Mon Nov 23 09:47:27 2009 Subject: 7.2 dies in zfs In-Reply-To: <20091123090121.GA59823@icarus.home.lan> References: <4B066B13.1070006@freebsd.org> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> <20091123090121.GA59823@icarus.home.lan> Message-ID: On Nov 23, 2009, at 10:01 AM, Jeremy Chadwick wrote: > On Mon, Nov 23, 2009 at 09:41:43AM +0100, Borja Marcos wrote: >> On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: >>> >>>> Try running FreeBSD 7-Stable to get the latest ZFS version which on >>>> FreeBSD is 13 >>> >>> that is what i am running. RELENG_7 >> >> I've been following ZFS on FreeBSD long ago, and it really seems to be stable on 8.0/amd64. >> Even Sun Microsystems say that ZFS is better used on a 64 bit system, they don't recommend it >> on the 32 bit version of Solaris. >> >> That said, there's still an outstanding bug, I managed to deadlock it but the condition is easy to avoid. > > Please provide details of this deadlock (PR, kernel output, scenario > details, etc.), and details of how to avoid it. Of course, it's been discussed on freebsd-fs, that's why I didn's cross-post. I'm making a heavy usage of zfs send/receive to keep a replica of a dataset. ZFS can deadlock if you are doing a zfs send and zfs receive (I'm using incremental snapshots) and at the same time you have reading activity on the destination dataset. Imagine this: Machine 1 is the origin, machine 2 is the destination: machine 1: zfs send -i pool/dataset@first pool/dataset@second | ssh machine2 zfs receive -d pool And while this is running, I have some activity going on with pool/dataset. Easy to replicate if pool/dataset contains /usr/obj and you are doing a make buildworld on the first machine, doing frequent replicas (30 second intervals) while on the second machine you keep a job reading it, I did the tests with a tar process copying the /usr/obj tree to another location. However, if you can ensure that the destination dataset is not read while the zfs receive is working, there is no problem at all, zfs send -i/zfs receives work like a charm, even at 30 second intervals. Borja. From rupesh.agrawal at verveos2i.com Mon Nov 23 11:25:25 2009 From: rupesh.agrawal at verveos2i.com (Rupesh Agrawal ) Date: Mon Nov 23 11:26:50 2009 Subject: Christmas Administrators - Recruitment Support Services Message-ID: <20091123105443.6B517398043@mdreg2.mailserve.net> ? Most of our recruitment clients recognise Christmas time as being the ideal opportunity to undertake an annual clean up of their databases to have their back offices ship shape for the New Year. ? ?45.00 per day ? This is the cost of a FULL-TIME administrator This is the cost of a FULL-TIME administrator working 8 hrs per day This is the cost of a FULL-TIME administrator working 8 hrs per day with only you as a client ? ? Verveoffshore Recruitment Process Outsourcing ? We offer flexible solutions to fit around your business ? ? ? Kind Regards, ? Rupesh Agrawal | Manager - Client Services ? VerveOS2i?? |? India? |? Phone:+91 20-41056789?Ext. 6712 |? E-mail: rupesh.agrawal@verveos2i.com |? Website: www.verveos2i.com ? CONFIDENTIALITY & DISCLAIMER: This E-mail from VerveOS2i ?is confidential. It may also be legally privileged. If you are not the intended receiver, you may not copy, reproduce, forward, disclose, disseminate or use any part of it. If you have received this message by slip, delete it and all copies from your system and notify the sender immediately by return E-mail. We do not guarantee the security of Internet communications and are not liable for any errors or omissions. ? We are a responsible email marketing team and comply with necessary regulations. Most often we buy email lists from opt-in repositories and carry our necessary checks. If this email has come to you by error or if you need us to remove your ID from our emailing list, please reply to this email with "REMOVE" on the subject line. From scottl at samsco.org Mon Nov 23 15:09:01 2009 From: scottl at samsco.org (Scott Long) Date: Mon Nov 23 15:09:08 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: References: <200910150853.49850.jhb@freebsd.org> Message-ID: <6B4DCB23-179D-4163-923F-24FC66303086@samsco.org> Did you ever get a resolution for this? The 6.x bugs definitely need to be fixed. The reported timeouts on 7.x might be due to the adapter taking a log time to do the command. Scott On Oct 22, 2009, at 8:30 AM, pluknet wrote: > 2009/10/15 John Baldwin : >> On Thursday 15 October 2009 5:51:19 am pluknet wrote: >>> Hi. >>> >>> This is 7.2-R. Seen on IBM x3650M2. >>> >>> During the boot I get those endless looping kernel messages while on >>> mfi(4) attach phase. >>> It's getting more odd since 7.2 booted and worked fine on exactly >>> this >>> server model >>> months ago (on different box though).. Any hints? >> >> We just had some boxes die like this (but spewing a different loop >> of messages >> on boot related to continuously scheduling patrol reads and >> consistency >> checks that finished immediately) at work. We fixed them by >> swapping out the >> controller. We might try stick them in a different box and >> reflashing them >> using mfiutil(8) to see if it's some sort of corrupted state that >> flashing >> the adapter fixes. >> >> In your case it looks lik the firmware keeps crashing and restarting. >> > > Some more thoughts.. > > There was a problem I got with 'MegaCli -AdpBbuCmd -BbuLearn -aall' > command. > On 6.2-R process slept on mfiwait wchan: > > db> bt 14734 > Tracing pid 14734 tid 100135 td 0xc93f8190 > sched_switch(c93f8190,0,1) at sched_switch+0x143 > mi_switch(1,0,c93f8190,f9a32acc,c06a43a4,...) at mi_switch+0x1ba > sleepq_switch(c8c6b0d0) at sleepq_switch+0x87 > sleepq_wait(c8c6b0d0,0,c93f8190,c8c6b0d0,c8c25800,...) at sleepq_wait > +0x5c > msleep(c8c6b0d0,c8c25954,4c,c090acbc,0) at msleep+0x269 > mfi_wait_command(c8c25800,c8c6b0d0,0,0,cc382460,...) at > mfi_wait_command+0xa8 > mfi_ioctl(c8c31300,c1144d01,cc870a00,1,c93f8190,...) at mfi_ioctl > +0x485 > devfs_ioctl_f(c90a2750,c1144d01,cc870a00,c9048000,c93f8190) at > devfs_ioctl_f+0xaf > ioctl(c93f8190,f9a32d04) at ioctl+0x445 > syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = > 0xbfbfe88c, ebp = 0xbfbfe8b8 --- > > Then: > mfi0: COMMAND 0xc8c6b0d0 TIMEOUT AFTER 51 SECONDS > mfi0: COMMAND 0xc8c61d50 TIMEOUT AFTER 49 SECONDS > mfi0: COMMAND 0xc8c61850 TIMEOUT AFTER 49 SECONDS > > > On 6.4-R MegaCli throws a page fault due to NULL deref > in mfi_data_cb():cm->cm_sg (see below). > > There was past 6.4 backport mentioning > "fix some bugs in the API for the management ioctl." > With this patch I have no longer panic and/or locks. > > Thanks to LSI now on 7.2-R (and on patched 6.4-R) it returns an error: > # ./MegaCli -AdpBbuCmd -BbuLearn -aall > > Adapter 0: BBU Learn Failed > > Exit Code: 0x32 > > > db> bt > Tracing pid 43059 tid 101363 td 0xcf46e680 > mfi_data_cb(c9cfae00,c9cc3e00,1,0) at mfi_data_cb+0x5e > bus_dmamap_load(c9cd7c80,0,caf86270,0,c0597240,c9cfae00,0) at > bus_dmamap_load+0x4a1 > mfi_mapcmd(c9cc3800,c9cfae00) at mfi_mapcmd+0x31 > mfi_startio(c9cc3800) at mfi_startio+0x9b > mfi_wait_command(c9cc3800,c9cfae00,0,0,caf86270,...) at > mfi_wait_command+0x89 > mfi_ioctl(c9cf7200,c1144d01,d3fb6200,1,cf46e680,...) at mfi_ioctl > +0x52a > devfs_ioctl_f(d1a551b0,c1144d01,d3fb6200,cbf52c80,cf46e680) at > devfs_ioctl_f+0xaf > ioctl(cf46e680,fbd91d04) at ioctl+0x445 > syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = > 0xbfbfe88c, ebp = 0xbfbfe8b8 > > #9 0xc08cbb1a in calltrap () at /usr/src/sys/i386/i386/exception.s: > 139 > #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, > nsegs=1, > ---Type to continue, or q to quit--- > error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 > #11 0xc08c7afd in bus_dmamap_load (dmat=0xc8a6f100, map=0xac89e000, > buf=0xc8a5ac60, buflen=0, callback=0xc0597240 , > callback_arg=0xc8a744b0, flags=0) > at /usr/src/sys/i386/i386/busdma_machdep.c:733 > #12 0xc059721d in mfi_mapcmd (sc=0xc8a49800, cm=0xc8a49e00) > at /usr/src/sys/dev/mfi/mfi.c:1452 > #13 0xc0597177 in mfi_startio (sc=0xc8a49800) > at /usr/src/sys/dev/mfi/mfi.c:1436 > #14 0xc0595f09 in mfi_wait_command (sc=0xc8a49800, cm=0xc8a744b0) > at /usr/src/sys/dev/mfi/mfi.c:822 > #15 0xc059840a in mfi_ioctl (dev=0xac89e000, cmd=0, arg=0xc8de8800 > "", flag=1, > td=0xc8a5ac60) at /usr/src/sys/dev/mfi/mfi.c:2061 > #16 0xc06598b7 in devfs_ioctl_f (fp=0xc902dc18, com=3239333121, > data=0xc8de8800, cred=0xc9052980, td=0xc8e2dd00) > at /usr/src/sys/fs/devfs/devfs_vnops.c:480 > #17 0xc06d3a11 in ioctl (td=0xc8e2dd00, uap=0xeb37bd04) at file.h:265 > > (kgdb) f 10 > #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, > nsegs=1, > error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 > 1488 sgl->sg32[i].addr = segs[i].ds_addr; > (kgdb) list > 1483 return; > 1484 } > 1485 > 1486 if ((sc->mfi_flags & MFI_FLAGS_SG64) == 0) { > 1487 for (i = 0; i < nsegs; i++) { > 1488 sgl->sg32[i].addr = segs[i].ds_addr; > 1489 sgl->sg32[i].len = segs[i].ds_len; > 1490 } > 1491 } else { > 1492 for (i = 0; i < nsegs; i++) { > (kgdb) p i > $1 = 0 > (kgdb) p *segs > $3 = {ds_addr = 2457600, ds_len = 65536} > (kgdb) p sgl > $4 = (union mfi_sgl *) 0x0 > (kgdb) p *cm > $6 = {cm_link = {tqe_next = 0x0, tqe_prev = 0xc8a49814}, > cm_timestamp = 0, > cm_sc = 0xc8a49800, cm_frame = 0xe8fee680, cm_frame_busaddr = > 3748513408, > cm_sense = 0xe904c780, cm_sense_busaddr = 3749103488, cm_dmamap = > 0x0, > cm_sg = 0x0, cm_data = 0xc8a5ac60, cm_len = 0, cm_total_frame_size > = 0, > cm_extra_frames = 0, cm_flags = 6, cm_aen_abort = 0, cm_complete = 0, > cm_private = 0x0, cm_index = 15, cm_error = 0} > > > -- > wbr, > pluknet > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From pluknet at gmail.com Mon Nov 23 15:27:00 2009 From: pluknet at gmail.com (pluknet) Date: Mon Nov 23 15:27:07 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: <6B4DCB23-179D-4163-923F-24FC66303086@samsco.org> References: <200910150853.49850.jhb@freebsd.org> <6B4DCB23-179D-4163-923F-24FC66303086@samsco.org> Message-ID: 2009/11/23 Scott Long : > Did you ever get a resolution for this? ?The 6.x bugs definitely need to be > fixed. ?The reported timeouts on 7.x might be due to the adapter taking a > log time to do the command. > > Scott An "endless loop kernel output" on boot always solved with clearing logs with MegaCli -AdpEventLog -GetEventLogInfo -aAll. As for BBULearn issue, I just tested it again on one of my boxes: # ./MegaCli -AdpBbuCmd -BbuLearn -aall Adapter 0: BBU Learn Succeeded. Exit Code: 0x00 So it seems to work. I see no problems. mfi0: 3748 (312279437s/0x0008/info) - Battery relearn started mfi0: 3749 (312279437s/0x0008/WARN) - BBU disabled; changing WB virtual disks to WT mfi0: 3750 (312279437s/0x0001/info) - Policy change on VD 00/0 to [ID=00,dcp=6d,ccp=6c,ap=0,dc=0,dbgi=0] from [ID=00,dcp=6d,ccp=6d,ap=0,dc=0,dbgi=0] mfi0: 3751 (312279442s/0x0008/info) - Battery is discharging mfi0: 3752 (312279442s/0x0008/info) - Battery relearn in progress > > On Oct 22, 2009, at 8:30 AM, pluknet wrote: > >> 2009/10/15 John Baldwin : >>> >>> On Thursday 15 October 2009 5:51:19 am pluknet wrote: >>>> >>>> Hi. >>>> >>>> This is 7.2-R. Seen on IBM x3650M2. >>>> >>>> During the boot I get those endless looping kernel messages while on >>>> mfi(4) attach phase. >>>> It's getting more odd since 7.2 booted and worked fine on exactly this >>>> server model >>>> months ago (on different box though).. Any hints? >>> >>> We just had some boxes die like this (but spewing a different loop of >>> messages >>> on boot related to continuously scheduling patrol reads and consistency >>> checks that finished immediately) at work. ?We fixed them by swapping out >>> the >>> controller. ?We might try stick them in a different box and reflashing >>> them >>> using mfiutil(8) to see if it's some sort of corrupted state that >>> flashing >>> the adapter fixes. >>> >>> In your case it looks lik the firmware keeps crashing and restarting. >>> >> >> Some more thoughts.. >> >> There was a problem I got with 'MegaCli -AdpBbuCmd -BbuLearn -aall' >> command. >> On 6.2-R process slept on mfiwait wchan: >> >> db> bt 14734 >> Tracing pid 14734 tid 100135 td 0xc93f8190 >> sched_switch(c93f8190,0,1) at sched_switch+0x143 >> mi_switch(1,0,c93f8190,f9a32acc,c06a43a4,...) at mi_switch+0x1ba >> sleepq_switch(c8c6b0d0) at sleepq_switch+0x87 >> sleepq_wait(c8c6b0d0,0,c93f8190,c8c6b0d0,c8c25800,...) at sleepq_wait+0x5c >> msleep(c8c6b0d0,c8c25954,4c,c090acbc,0) at msleep+0x269 >> mfi_wait_command(c8c25800,c8c6b0d0,0,0,cc382460,...) at >> mfi_wait_command+0xa8 >> mfi_ioctl(c8c31300,c1144d01,cc870a00,1,c93f8190,...) at mfi_ioctl+0x485 >> devfs_ioctl_f(c90a2750,c1144d01,cc870a00,c9048000,c93f8190) at >> devfs_ioctl_f+0xaf >> ioctl(c93f8190,f9a32d04) at ioctl+0x445 >> syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = >> 0xbfbfe88c, ebp = 0xbfbfe8b8 --- >> >> Then: >> mfi0: COMMAND 0xc8c6b0d0 TIMEOUT AFTER 51 SECONDS >> mfi0: COMMAND 0xc8c61d50 TIMEOUT AFTER 49 SECONDS >> mfi0: COMMAND 0xc8c61850 TIMEOUT AFTER 49 SECONDS >> >> >> On 6.4-R MegaCli throws a page fault due to NULL deref >> in mfi_data_cb():cm->cm_sg (see below). >> >> There was past 6.4 backport mentioning >> "fix some bugs in the API for the management ioctl." >> With this patch I have no longer panic and/or locks. >> >> Thanks to LSI now on 7.2-R (and on patched 6.4-R) it returns an error: >> # ./MegaCli -AdpBbuCmd -BbuLearn -aall >> >> Adapter 0: BBU Learn Failed >> >> Exit Code: 0x32 >> >> >> db> bt >> Tracing pid 43059 tid 101363 td 0xcf46e680 >> mfi_data_cb(c9cfae00,c9cc3e00,1,0) at mfi_data_cb+0x5e >> bus_dmamap_load(c9cd7c80,0,caf86270,0,c0597240,c9cfae00,0) at >> bus_dmamap_load+0x4a1 >> mfi_mapcmd(c9cc3800,c9cfae00) at mfi_mapcmd+0x31 >> mfi_startio(c9cc3800) at mfi_startio+0x9b >> mfi_wait_command(c9cc3800,c9cfae00,0,0,caf86270,...) at >> mfi_wait_command+0x89 >> mfi_ioctl(c9cf7200,c1144d01,d3fb6200,1,cf46e680,...) at mfi_ioctl+0x52a >> devfs_ioctl_f(d1a551b0,c1144d01,d3fb6200,cbf52c80,cf46e680) at >> devfs_ioctl_f+0xaf >> ioctl(cf46e680,fbd91d04) at ioctl+0x445 >> syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = >> 0xbfbfe88c, ebp = 0xbfbfe8b8 >> >> #9 ?0xc08cbb1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, nsegs=1, >> ---Type to continue, or q to quit--- >> ? error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 >> #11 0xc08c7afd in bus_dmamap_load (dmat=0xc8a6f100, map=0xac89e000, >> ? buf=0xc8a5ac60, buflen=0, callback=0xc0597240 , >> ? callback_arg=0xc8a744b0, flags=0) >> ? at /usr/src/sys/i386/i386/busdma_machdep.c:733 >> #12 0xc059721d in mfi_mapcmd (sc=0xc8a49800, cm=0xc8a49e00) >> ? at /usr/src/sys/dev/mfi/mfi.c:1452 >> #13 0xc0597177 in mfi_startio (sc=0xc8a49800) >> ? at /usr/src/sys/dev/mfi/mfi.c:1436 >> #14 0xc0595f09 in mfi_wait_command (sc=0xc8a49800, cm=0xc8a744b0) >> ? at /usr/src/sys/dev/mfi/mfi.c:822 >> #15 0xc059840a in mfi_ioctl (dev=0xac89e000, cmd=0, arg=0xc8de8800 "", >> flag=1, >> ? td=0xc8a5ac60) at /usr/src/sys/dev/mfi/mfi.c:2061 >> #16 0xc06598b7 in devfs_ioctl_f (fp=0xc902dc18, com=3239333121, >> ? data=0xc8de8800, cred=0xc9052980, td=0xc8e2dd00) >> ? at /usr/src/sys/fs/devfs/devfs_vnops.c:480 >> #17 0xc06d3a11 in ioctl (td=0xc8e2dd00, uap=0xeb37bd04) at file.h:265 >> >> (kgdb) f 10 >> #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, nsegs=1, >> ? error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 >> 1488 ? ? ? ? ? ? ? ? ? ? ? ? ? ?sgl->sg32[i].addr = segs[i].ds_addr; >> (kgdb) list >> 1483 ? ? ? ? ? ? ? ? ? ?return; >> 1484 ? ? ? ? ? ?} >> 1485 >> 1486 ? ? ? ? ? ?if ((sc->mfi_flags & MFI_FLAGS_SG64) == 0) { >> 1487 ? ? ? ? ? ? ? ? ? ?for (i = 0; i < nsegs; i++) { >> 1488 ? ? ? ? ? ? ? ? ? ? ? ? ? ?sgl->sg32[i].addr = segs[i].ds_addr; >> 1489 ? ? ? ? ? ? ? ? ? ? ? ? ? ?sgl->sg32[i].len = segs[i].ds_len; >> 1490 ? ? ? ? ? ? ? ? ? ?} >> 1491 ? ? ? ? ? ?} else { >> 1492 ? ? ? ? ? ? ? ? ? ?for (i = 0; i < nsegs; i++) { >> (kgdb) p i >> $1 = 0 >> (kgdb) p *segs >> $3 = {ds_addr = 2457600, ds_len = 65536} >> (kgdb) p sgl >> $4 = (union mfi_sgl *) 0x0 >> (kgdb) p *cm >> $6 = {cm_link = {tqe_next = 0x0, tqe_prev = 0xc8a49814}, cm_timestamp = 0, >> ?cm_sc = 0xc8a49800, cm_frame = 0xe8fee680, cm_frame_busaddr = 3748513408, >> ?cm_sense = 0xe904c780, cm_sense_busaddr = 3749103488, cm_dmamap = 0x0, >> ?cm_sg = 0x0, cm_data = 0xc8a5ac60, cm_len = 0, cm_total_frame_size = 0, >> ?cm_extra_frames = 0, cm_flags = 6, cm_aen_abort = 0, cm_complete = 0, >> ?cm_private = 0x0, cm_index = 15, cm_error = 0} >> >> >> -- >> wbr, >> pluknet >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- wbr, pluknet From matt at madhaus.cns.utoronto.ca Mon Nov 23 16:11:00 2009 From: matt at madhaus.cns.utoronto.ca (Matt Wilks) Date: Mon Nov 23 16:11:08 2009 Subject: NSIS compile failed on FreeBSD 7.2 In-Reply-To: <20091120194613.GA81572@icarus.home.lan> References: <4B02B7D4.7020502@madhaus.cns.utoronto.ca> <4B06E274.3090207@madhaus.cns.utoronto.ca> <20091120194613.GA81572@icarus.home.lan> Message-ID: <4B0AB408.1010500@madhaus.cns.utoronto.ca> > If that's indeed the case, then the port Makefile needs to be modified > to reject building on any architectures other than i386. This should > suffice: > > ONLY_FOR_ARCHS= i386 > > If you could file a PR on this matter, the FreeBSD Project folks would > likely appreciate it. :-) There isn't actually a FreeBSD port for this project. I was compiling source obtained from the NSIS sourceforge page. -- Matt Wilks Colossians 2:6-7 University of Toronto Information Security, I+TS (416) 978-3328 matt@madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1 From spork at bway.net Mon Nov 23 21:28:24 2009 From: spork at bway.net (Charles Sprickman) Date: Mon Nov 23 21:28:31 2009 Subject: panic in 7.2 (ffs_alloc.c?) In-Reply-To: References: Message-ID: Just a follow-up... The machine was waiting for a manual fsck - this crash seemed to scramble things up pretty good, it hit the jail partition hard and seemed to touch others that were quiet at the time. I'm re-running mstone with an even heavier load to see if I can reproduce this again. Full verbose dmesg: http://pastie.org/711839 Should I bother with a PR or anything on this? Doesn't look like a hardware issue to me. It seems like there could be a nasty bug waiting in the UFS2 code somewhere, does anyone want to persue this at all? I have the dump available for anyone that wants it. Thanks, Charles On Sun, 22 Nov 2009, Charles Sprickman wrote: > Howdy, > > I'm not expert at getting info out of a dump, but I'll do my best to provide > some information. > > This is a Dell PE2970 w/PERC6/i RAID running FreeBSD 7.2/amd64. Brand new > box, has been doing very light work for about two weeks. Last night I > started a very long mstone run on a jailed mail server and found that quite a > way into this burn-in, the box paniced. I was going to put it in service > Monday (after punishing it all weekend). Looking for some input on what the > root cause is and whether going to a -stable snapshot might be worthwhile. > > I can tell you there was a good deal of disk activity at the time in the jail > - mstone was simulating 100 POP and SMTP clients hitting the machine at once. > This is qmail+courier. So messages are coming in, hitting the queue, hitting > a user's maildir, getting read and deleted via the POP "client" over and over > again. I do see lots of "ffs_*" stuff in the backtrace, which is a little > scary. > > Here's my stab at a kgdb session (also @ pastie for easier reading: > http://pastie.org/709671): > > [root@bigmail /usr/obj/usr/src/sys/BWAY7-64]# kgdb kernel.debug > /var/crash/vmcore.0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x12d4b9f5c > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8050382e > stack pointer = 0x10:0xffffffff281a75b0 > frame pointer = 0x10:0xffffff000455f800 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 6324 (vdelivermail) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 12d0h32m3s > Physical memory: 6130 MB > Dumping 725 MB: 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 > 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 > 166 150 134 118 102 86 70 54 38 22 6 > > Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from > /boot/kernel/nullfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from > /boot/kernel/fdescfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/fdescfs.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > #3 0xffffffff8034cba2 in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff80574823 in trap_fatal (frame=0xffffff00046c8000, eva=Variable > "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:757 > #5 0xffffffff80574bf5 in trap_pfault (frame=0xffffffff281a7500, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:673 > #6 0xffffffff80575534 in trap (frame=0xffffffff281a7500) > at /usr/src/sys/amd64/amd64/trap.c:444 > #7 0xffffffff8055969e in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:209 > #8 0xffffffff8050382e in ffs_realloccg (ip=0xffffff00267f75c0, lbprev=0, > bprev=6288224785898156086, bpref=593305256, osize=0, nsize=2048, > flags=33619968, cred=0xffffff00927fe800, bpp=0xffffffff281a7800) > at /usr/src/sys/ufs/ffs/ffs_alloc.c:1349 > #9 0xffffffff80506e8e in ffs_balloc_ufs2 (vp=0xffffff0027a64dc8, > startoffset=Variable "startoffset" is not available. > ) > at /usr/src/sys/ufs/ffs/ffs_balloc.c:692 > #10 0xffffffff805223e5 in ffs_write (ap=0xffffffff281a7a10) > at /usr/src/sys/ufs/ffs/ffs_vnops.c:724 > #11 0xffffffff805a0645 in VOP_WRITE_APV (vop=0xffffffff80793d20, > a=0xffffffff281a7a10) at vnode_if.c:691 > #12 0xffffffff803dd731 in vn_write (fp=0xffffff001027cd00, > uio=0xffffffff281a7b00, active_cred=Variable "active_cred" is not > available. > ) at vnode_if.h:373 > #13 0xffffffff80388768 in dofilewrite (td=0xffffff00046c8000, fd=5, > fp=0xffffff001027cd00, auio=dwarf2_read_address: Corrupted DWARF > expression. > ) at file.h:257 > #14 0xffffffff80388a6e in kern_writev (td=0xffffff00046c8000, fd=5, > auio=0xffffffff281a7b00) at /usr/src/sys/kern/sys_generic.c:402 > #15 0xffffffff80388aec in write (td=0x800, uap=0x12d4b9f50) > at /usr/src/sys/kern/sys_generic.c:318 > #16 0xffffffff80596a66 in ia32_syscall (frame=0xffffffff281a7c80) > at /usr/src/sys/amd64/ia32/ia32_syscall.c:182 > #17 0xffffffff80559ad0 in Xint0x80_syscall () at ia32_exception.S:65 > #18 0x0000000028167928 in ?? () > Previous frame inner to this frame (corrupt stack?) > > Full dmesg, verbose boot and kernel config at pastie as well. Actually no > verbose boot... I rebooted the box after setting verbose boot with > "nextboot" and it didn't come back. Hrmph. No remote console, so I don't > know what's up, perhaps waiting on some manual fsck action. > > Thanks, > > Charles > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From rmacklem at uoguelph.ca Mon Nov 23 21:37:31 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Nov 23 21:37:38 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: <20091027164159.GU841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: On Tue, 27 Oct 2009, Olaf Seibert wrote: > I see an annoying behaviour with NFS over TCP. It happens both with nfs > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > some Linux or perhaps Solaris, I'm not entirely sure. > [good stuff snipped...] > > Though technically the connection is closed in one direction > only, the intention of the server seems clear, and it would be better to > be careful and make a new connection right away. > I believe that r199293 committed to stable/8 should fix this. It did not make it into FreeBSD8.0, so users of FreeBSD8.0 will need to switch to using "udp" or apply the patch themselves, if slow reconnects after a non-FreeBSD NFS server are causing them grief. rick From gaijin.k at gmail.com Tue Nov 24 01:53:32 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Tue Nov 24 01:53:39 2009 Subject: HEADS UP: major CAM ATA MFC In-Reply-To: <1258688373.1678.4.camel@RabbitsDen> References: <4B03322A.2080608@FreeBSD.org> <1258688373.1678.4.camel@RabbitsDen> Message-ID: <1259027604.1654.2.camel@RabbitsDen> On Thu, 2009-11-19 at 22:43 -0500, Alexandre "Sunny" Kovalenko wrote: > On Wed, 2009-11-18 at 01:30 +0200, Alexander Motin wrote: > > Feedbacks are welcome as always. > > > Works here (ThinkPad X60): > > ahci0: port > 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf > mem 0xee444400-0xee4447ff irq 16 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > > RabbitsDen# camcontrol tags ada0 > (pass0:ahcich0:0:0:0): device openings: 32 > RabbitsDen# Might be of interest for some other people out there: with this driver, I can suspend/resume my ThinkPad X60 with UP kernel -- the original ATA driver was going into the timeout loop upon resume. -- Alexandre Kovalenko (????????? ?????????) From dwilde1 at gmail.com Tue Nov 24 03:14:22 2009 From: dwilde1 at gmail.com (Don Wilde) Date: Tue Nov 24 03:14:35 2009 Subject: Don Wilde wants to connect on LinkedIn Message-ID: <1509792466.7126047.1259030799504.JavaMail.app@ech3-cdn12.prod> LinkedIn ------------ Don Wilde requested to add you as a connection on LinkedIn: ------------------------------------------ Dear Valeriy, I'm merging my GMail with Liked-In so I can easily learn more about what's new in your lives. Please accept my humble invitation and feel free to personally reconnect and strengthen the connection! :D - Don Wilde Accept invitation from Don Wilde http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I39742775_4/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYQnPkTdP8QdPAPiiZWd44MblxWiOYPdz8Md3sPe3wLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Don Wilde http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I39742775_4/d5YRdPsOd3sVcQALqnpPbOYWrSlI/svi/ ------------------------------------------ DID YOU KNOW you can be the first to know when a trusted member of your network changes jobs? With Network Updates on your LinkedIn home page, you'll be notified as members of your network change their current position. Be the first to know and reach out! http://www.linkedin.com/ ------ (c) 2009, LinkedIn Corporation From dikshie at gmail.com Tue Nov 24 06:24:41 2009 From: dikshie at gmail.com (dikshie) Date: Tue Nov 24 06:24:48 2009 Subject: tcpdump/libpcap core dump on amd64. Message-ID: <910e60e80911232159t2c52d081nce0d7ecfde713362@mail.gmail.com> Hi, I have experience core dump signal 11 using tcpdump in amd64 arch. 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #14: Tue Nov 24 03:28:14 JST 2009 tcpdump -nvi em2 -> no core dump tcpdump -nvi em2 -c 100 -> core dump i try in i386 and the result: no coredump here's the core file: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `tcpdump'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpcap.so.7...done. Loaded symbols for /lib/libpcap.so.7 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800b244e7 in free () from /lib/libc.so.7 (gdb) bt #0 0x0000000800b244e7 in free () from /lib/libc.so.7 #1 0x00000008006f6a75 in pcap_cleanup_live_common (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:1158 #2 0x00000008006f7768 in pcap_cleanup_bpf (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1218 #3 0x00000008006f65ee in pcap_close (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:1232 #4 0x0000000000452b04 in main (argc=Variable "argc" is not available. ) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1230 thanks! -- -dikshie- From gjin at ubicom.com Tue Nov 24 08:16:17 2009 From: gjin at ubicom.com (Guojun Jin) Date: Tue Nov 24 08:16:26 2009 Subject: 8.0-RC USB/FS problem References: <200911221047.20362.hselasky@c2i.net> Message-ID: Freshly installed 8.0-RELEASE on two differnt machines, and USB stick work well so far, but the USB hard drive still has crash on this SMP (4-core AMD phenom 9600) during the dump/restore. I will try it on the single CPU machine tomorrow. Re-tested dump/restore with FreeBSD 6.3/6.4 on this SMP machine and they are working well. Also the another strange thing ocurred during the mount a partition on /tmp, which ended with two /tmp, and the last one mounted is on the top (the first should be hidden): : df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 756750 165484 530726 24% / devfs 1 1 0 100% /dev /dev/ad0s2e 43194318 27833648 11905126 70% /data /dev/ad0s2d 9135182 5870390 2533978 70% /home /dev/ad0s1e 507630 34882 432138 7% /tmp /dev/ad0s1f 13246730 1424522 10762470 12% /usr /dev/ad0s1d 5077038 12700 4658176 0% /var /dev/da0s2 661176 487660 120622 80% /mnt /dev/da1s3d 9135182 4 8404364 0% /dist /dev/da1s3e 74938948 4 68943830 0% /tmp : df /tmp Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da1s3e 74938948 4 68943830 0% /tmp -----Original Message----- From: Guojun Jin Sent: Sun 11/22/2009 7:59 PM To: Hans Petter Selasky; freebsd-usb@freebsd.org Cc: bugs@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem >From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at different USB access phase at each time. dd if=/dev/zero of=/dev/da0 count=1000 bs=4k sysinstall partition slice 1 (da0s1) 18GB ID=12 slice 2 (da0s2) 10-15GB Id=165 slice 3 (da0s3) rest ID=165 W ---> OK label da0s3d 9GB /mnt da0s3e rest /dist W ---> da0s3e ---- device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r----- 1 root operator 0, 97 Nov 22 11:23 /dev/da0 crw-r----- 1 root operator 0, 98 Nov 22 11:23 /dev/da0s1 crw-r----- 1 root operator 0, 99 Nov 22 11:23 /dev/da0s2 crw-r----- 1 root operator 0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r----- 1 root operator 0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=-1) After system reboot, and repeated above processes, the da0s3e was mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 8.0-RELEASE to see if anything will improve. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it just > partition format issue; but system crashed during dump/restore on s3e, and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, is to blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a problem. On FreeBSD we just try a software reset via the control endpoint. I guess that it is a device problem you are seeing. The USB stack in FreeBSD is faster than the old one, and maybe the faster queueing of mass storage requests trigger some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=-1 --HPS From hselasky at c2i.net Tue Nov 24 08:31:44 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Nov 24 08:31:58 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: References: Message-ID: <200911240933.19329.hselasky@c2i.net> On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS From jespasac at minibofh.org Tue Nov 24 12:24:35 2009 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Tue Nov 24 12:24:45 2009 Subject: gjournal + gmirror Message-ID: <4B0BD02D.6010406@minibofh.org> Hi all, I've configured a new disk with two journaled partitions (/var and /usr). All works fine until this point. Next I add a new disk and I set up a gmirror as I've done always without problems. But when I reboot the system, I always get a nasty 'mountroot' message. I've cheched the gmirror creation process (module in /boot/loader.conf, the modified fstab... all) and all is correct. I suspect some gjournal+gmirror especial issues maybe.... ?Any clue? FreeBSD 7.2 AMD64 -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From to.my.trociny at gmail.com Tue Nov 24 14:53:41 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Nov 24 14:53:47 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop Message-ID: <86aayc7z4g.fsf@zhuzha.ua1> Hi, I have problems with compiling our application under 8.0. It fails due to these definitions in pthread.h that look like a typo or incorrectly applied patch: 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ 171 { \ 172 struct _pthread_cleanup_info __cleanup_info__; \ 173 __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ 174 &__cleanup_info__); \ 175 { 176 177 #define pthread_cleanup_pop(execute) \ 178 } \ 179 __pthread_cleanup_pop_imp(execute); \ 180 } This patch fixes the problem for me: --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 @@ -172,10 +172,10 @@ struct _pthread_cleanup_info __cleanup_info__; \ __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ &__cleanup_info__); \ - { + } #define pthread_cleanup_pop(execute) \ - } \ + { \ __pthread_cleanup_pop_imp(execute); \ } -- Mikolaj Golub From pluknet at gmail.com Tue Nov 24 15:14:01 2009 From: pluknet at gmail.com (pluknet) Date: Tue Nov 24 15:14:08 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <86aayc7z4g.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> Message-ID: 2009/11/24 Mikolaj Golub : > Hi, > > I have problems with compiling our application under 8.0. > > It fails due to these definitions in pthread.h that look like a typo or > incorrectly applied patch: > > ? ?170 #define ? ? ? ? pthread_cleanup_push(cleanup_routine, cleanup_arg) ? ? ? ? ? ? ?\ > ? ?171 ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > ? ?172 ? ? ? ? ? ? ? ? ? ? ? ? struct _pthread_cleanup_info __cleanup_info__; ? ? ? ? ?\ > ? ?173 ? ? ? ? ? ? ? ? ? ? ? ? __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > ? ?174 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &__cleanup_info__); ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > ? ?175 ? ? ? ? ? ? ? ? ? ? ? ? { > ? ?176 > ? ?177 #define ? ? ? ? pthread_cleanup_pop(execute) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > ? ?178 ? ? ? ? ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > ? ?179 ? ? ? ? ? ? ? ? ? ? ? ? __pthread_cleanup_pop_imp(execute); ? ? ? ? ? ? ? ? ? ? \ > ? ?180 ? ? ? ? ? ? ? ? } > Hi. No, this is made intentionally. P.S. I don't understand the reason in the second brackets pair though (lines 175,178), maybe these are because of comment to v1.43.. -- wbr, pluknet From to.my.trociny at gmail.com Tue Nov 24 15:18:34 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Nov 24 15:18:41 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <86aayc7z4g.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Tue\, 24 Nov 2009 16\:53\:35 +0200") References: <86aayc7z4g.fsf@zhuzha.ua1> Message-ID: <8663907xyy.fsf@zhuzha.ua1> On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote: > Hi, > > I have problems with compiling our application under 8.0. > > It fails due to these definitions in pthread.h that look like a typo or > incorrectly applied patch: > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ > 171 { \ > 172 struct _pthread_cleanup_info __cleanup_info__; \ > 173 __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > 174 &__cleanup_info__); \ > 175 { > 176 > 177 #define pthread_cleanup_pop(execute) \ > 178 } \ > 179 __pthread_cleanup_pop_imp(execute); \ > 180 } > > > This patch fixes the problem for me: I was hurry when said that the patch fixed the problem. The application compiled but later it crashed in pthread_cleanup_pop: (gdb) bt #0 0xbf4f9ee0 in ?? () #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 #5 0x00000000 in ?? () So, I don't know what these macros actually were supposed to be. They were introduced in r179662: Revision 1.43: download - view: text, markup, annotated - select for diffs Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu Branches: MAIN Diff to: previous 1.42: preferred, colored Changes since revision 1.42: +21 -2 lines SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, use stack space to keep cleanup information, this eliminates overhead of calling malloc() and free() in thread library. Discussed on: thread@ > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > @@ -172,10 +172,10 @@ > struct _pthread_cleanup_info __cleanup_info__; \ > __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > &__cleanup_info__); \ > - { > + } > > #define pthread_cleanup_pop(execute) \ > - } \ > + { \ > __pthread_cleanup_pop_imp(execute); \ > } -- Mikolaj Golub From tevans.uk at googlemail.com Tue Nov 24 15:32:59 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Tue Nov 24 15:33:06 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <8663907xyy.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> Message-ID: <2e027be00911240732u1ac60d31ucbbb65545636e6b@mail.gmail.com> On Tue, Nov 24, 2009 at 3:18 PM, Mikolaj Golub wrote: > > So, I don't know what these macros actually were supposed to be. They were > introduced in r179662: > > Revision 1.43: download - view: text, markup, annotated - select for diffs > Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu > Branches: MAIN > Diff to: previous 1.42: preferred, colored > Changes since revision 1.42: +21 -2 lines > > SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu > > Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, > use stack space to keep cleanup information, this eliminates overhead of > calling malloc() and free() in thread library. > > Discussed on: thread@ > http://lists.freebsd.org/pipermail/freebsd-threads/2008-May/004299.html Cheers Tom From kostikbel at gmail.com Tue Nov 24 15:34:27 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Nov 24 15:34:35 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <8663907xyy.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> Message-ID: <20091124153422.GT2331@deviant.kiev.zoral.com.ua> On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: > On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote: > > > Hi, > > > > I have problems with compiling our application under 8.0. > > > > It fails due to these definitions in pthread.h that look like a typo or > > incorrectly applied patch: > > > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ > > 171 { \ > > 172 struct _pthread_cleanup_info __cleanup_info__; \ > > 173 __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > > 174 &__cleanup_info__); \ > > 175 { > > 176 > > 177 #define pthread_cleanup_pop(execute) \ > > 178 } \ > > 179 __pthread_cleanup_pop_imp(execute); \ > > 180 } > > > > > > This patch fixes the problem for me: > > I was hurry when said that the patch fixed the problem. The application > compiled but later it crashed in pthread_cleanup_pop: > > (gdb) bt > #0 0xbf4f9ee0 in ?? () > #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 > #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 > #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 > #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 > #5 0x00000000 in ?? () > > So, I don't know what these macros actually were supposed to be. They were > introduced in r179662: > > Revision 1.43: download - view: text, markup, annotated - select for diffs > Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu > Branches: MAIN > Diff to: previous 1.42: preferred, colored > Changes since revision 1.42: +21 -2 lines > > SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu > > Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, > use stack space to keep cleanup information, this eliminates overhead of > calling malloc() and free() in thread library. > > Discussed on: thread@ > > > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > > @@ -172,10 +172,10 @@ > > struct _pthread_cleanup_info __cleanup_info__; \ > > __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > > &__cleanup_info__); \ > > - { > > + } > > > > #define pthread_cleanup_pop(execute) \ > > - } \ > > + { \ > > __pthread_cleanup_pop_imp(execute); \ > > } pthread_cleanup_push/pop are supposed to be used from the common lexical scope. Citation from SUSv4: These functions may be implemented as macros. The application shall ensure that they appear as statements, and in pairs within the same lexical scope (that is, the pthread_cleanup_push() macro may be thought to expand to a token list whose first token is '{' with pthread_cleanup_pop() expanding to a token list whose last token is the corresponding '}' ). Your change is wrong. Basically, the code should do pthread_cleanup_push(some_func, arh); something ... pthread_cleanup_pop(1); (1 denotes that some_func should be called). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091124/35a76e19/attachment.pgp From ume at freebsd.org Tue Nov 24 15:35:28 2009 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Tue Nov 24 15:35:36 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <8663907xyy.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> Message-ID: Hi, >>>>> On Tue, 24 Nov 2009 17:18:29 +0200 >>>>> Mikolaj Golub said: to.my.trociny> I was hurry when said that the patch fixed the problem. The application to.my.trociny> compiled but later it crashed in pthread_cleanup_pop: to.my.trociny> (gdb) bt to.my.trociny> #0 0xbf4f9ee0 in ?? () to.my.trociny> #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 to.my.trociny> #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 to.my.trociny> #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 to.my.trociny> #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 to.my.trociny> #5 0x00000000 in ?? () to.my.trociny> So, I don't know what these macros actually were supposed to be. They were to.my.trociny> introduced in r179662: Your modification to pthread.h is wrong. You need to write your code something like following: pthread_cleanup_push(); . . . do something . . . pthread_cleanup_pop(); This is not FreeBSD alone. pthread_cleanup_push() and pthread_cleanup_pop() are macro on Linux as well. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From to.my.trociny at gmail.com Tue Nov 24 15:47:47 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Nov 24 15:47:54 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <20091124153422.GT2331@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue\, 24 Nov 2009 17\:34\:22 +0200") References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> Message-ID: <861vjn9b6p.fsf@zhuzha.ua1> On Tue, 24 Nov 2009 17:34:22 +0200 Kostik Belousov wrote: > pthread_cleanup_push/pop are supposed to be used from the common > lexical scope. Citation from SUSv4: > > These functions may be implemented as macros. The application shall > ensure that they appear as statements, and in pairs within the same > lexical scope (that is, the pthread_cleanup_push() macro may be > thought to expand to a token list whose first token is '{' with > pthread_cleanup_pop() expanding to a token list whose last token is the > corresponding '}' ). > > Your change is wrong. > > Basically, the code should do > pthread_cleanup_push(some_func, arh); > something ... > pthread_cleanup_pop(1); > (1 denotes that some_func should be called). I see. Thank you. So it really looks like a bug in our application as pthread_cleanup_pop(1) is missed. I will tell our developers :-) -- Mikolaj Golub From gjin at ubicom.com Tue Nov 24 17:09:03 2009 From: gjin at ubicom.com (Guojun Jin) Date: Tue Nov 24 17:09:11 2009 Subject: 8.0-RC USB/FS problem References: <200911240933.19329.hselasky@c2i.net> Message-ID: Sorry for the typo -- it is public not pub in the middle. The others should be all public. http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Tue 11/24/2009 12:33 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 I'm not able to fetch this file. Could you extract the panic backtrace? --HPS From hselasky at c2i.net Tue Nov 24 17:11:54 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Nov 24 17:12:07 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: References: <200911240933.19329.hselasky@c2i.net> Message-ID: <200911241813.23616.hselasky@c2i.net> On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > Sorry for the typo -- it is public not pub in the middle. The others should > be all public. > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record --HPS > -----Original Message----- > From: Hans Petter Selasky [mailto:hselasky@c2i.net] > Sent: Tue 11/24/2009 12:33 AM > To: Guojun Jin > Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org > Subject: Re: 8.0-RC USB/FS problem > > On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 > > I'm not able to fetch this file. Could you extract the panic backtrace? > > --HPS From korvus at comcast.net Tue Nov 24 17:40:17 2009 From: korvus at comcast.net (Steve Polyack) Date: Tue Nov 24 17:40:32 2009 Subject: Panic possibly related to glabel/geom and siis(4) Message-ID: <4B0C1A72.3000301@comcast.net> I have a system running 8.0-PRERELEASE with multiple drives and SATA port multipliers (siis controllers and PMPs). All of the attached drives are labeled via glabel(8) and then included into a ZFS pool. During some testing to determine how the system would react to a dead drive (simulated by physically removing a drive during operation), I was able to produce a panic. Now, I know that the SATA PMP and siis(4) code to handle and recover from device errors is incomplete, but I believe the crash may be particular to using glabel'd drives. Basically, after removing a drive while the zpool is in use and issues 'camcontrol reset' and 'rescan' on the appropriate bus, the physical device associated with the drive disappears. In this case: (pass5:siisch7:0:15:0): lost device (pass5:siisch7:0:15:0): removing device entry (ada2:siisch7:0:0:0): lost device and /dev/ada2 disappears. However, the associated glabel /dev/label/bigdisk07 remains. Since my ZFS pool is created based on the drive glabels, I believe this is why ZFS never notices the drives disappear either. Do glabels typically go away after a physical device is lost? Should this not be the case? After some runtime with the physical device missing, a kernel panic is produced: ada2:siisch7:0:0:0): Synchronize cache failed (ada2:siisch7:0:0:0): removing device entry Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 14 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8035f375 stack pointer = 0x28:0xffffff800006db60 frame pointer = 0x28:0xffffff800006db70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) [thread pid 2 tid 100014 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> bt Tracing pid 2 tid 100014 td 0xffffff00014d4ab0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vdev_geom_release() at vdev_geom_release+0x33 vdev_geom_orphan() at vdev_geom_orphan+0x15c g_run_events() at g_run_events+0x104 g_event_procbody() at g_event_procbody+0x55 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800006dd30, rbp = 0 --- I'm open to try patches and other suggestions. Thanks. From freebsd at jdc.parodius.com Tue Nov 24 17:47:16 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Tue Nov 24 17:47:29 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: <200911241813.23616.hselasky@c2i.net> References: <200911240933.19329.hselasky@c2i.net> <200911241813.23616.hselasky@c2i.net> Message-ID: <20091124174714.GA2240@icarus.home.lan> On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: > On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > > Sorry for the typo -- it is public not pub in the middle. The others should > > be all public. > > > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No > address record > > --HPS > > > -----Original Message----- > > From: Hans Petter Selasky [mailto:hselasky@c2i.net] > > Sent: Tue 11/24/2009 12:33 AM > > To: Guojun Jin > > Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org > > Subject: Re: 8.0-RC USB/FS problem > > > > On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote: > > > http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 > > > > I'm not able to fetch this file. Could you extract the panic backtrace? > > > > --HPS The above issue is unrelated to the USB/FS problem. It looks like fetch(1) has a parser bug. Note the text portion between the URI and URL is colon-slash not colon-slash-slash like it should be. Reproduction: $ host www.daemonfun.com www.daemonfun.com is an alias for daemonfun.com. daemonfun.com has address 76.202.192.211 daemonfun.com mail is handled by 10 mh1.daemonfun.com. daemonfun.com mail is handled by 20 mh2.daemonfun.com. $ fetch http:/www.daemonfun.com/ fetch: http:/www.daemonfun.com/: No address record I haven't examined the code, but my guess is fetch is trying to do a lookup on the FQDN "http:/www.daemonfun.com/". Who wants to file a PR? :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dnelson at allantgroup.com Tue Nov 24 18:16:58 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Tue Nov 24 18:17:06 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: <20091124174714.GA2240@icarus.home.lan> References: <200911240933.19329.hselasky@c2i.net> <200911241813.23616.hselasky@c2i.net> <20091124174714.GA2240@icarus.home.lan> Message-ID: <20091124181654.GI89004@dan.emsphone.com> In the last episode (Nov 24), Jeremy Chadwick said: > On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: > > On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > > > Sorry for the typo -- it is public not pub in the middle. The others should > > > be all public. > > > > > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > > > > > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record > > The above issue is unrelated to the USB/FS problem. It looks like > fetch(1) has a parser bug. Note the text portion between the URI and URL > is colon-slash not colon-slash-slash like it should be. That's a typo in the URL, not a bug in fetch :) -- Dan Nelson dnelson@allantgroup.com From freebsd at jdc.parodius.com Tue Nov 24 18:50:18 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Tue Nov 24 18:50:25 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: <20091124181654.GI89004@dan.emsphone.com> References: <200911240933.19329.hselasky@c2i.net> <200911241813.23616.hselasky@c2i.net> <20091124174714.GA2240@icarus.home.lan> <20091124181654.GI89004@dan.emsphone.com> Message-ID: <20091124185016.GA3433@icarus.home.lan> On Tue, Nov 24, 2009 at 12:16:54PM -0600, Dan Nelson wrote: > In the last episode (Nov 24), Jeremy Chadwick said: > > On Tue, Nov 24, 2009 at 06:13:21PM +0100, Hans Petter Selasky wrote: > > > On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote: > > > > Sorry for the typo -- it is public not pub in the middle. The others should > > > > be all public. > > > > > > > > http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > > > > > > > > %fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2 > > > fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No address record > > > > The above issue is unrelated to the USB/FS problem. It looks like > > fetch(1) has a parser bug. Note the text portion between the URI and URL > > is colon-slash not colon-slash-slash like it should be. > > That's a typo in the URL, not a bug in fetch :) It's a bug in libfetch, specifically the fetchParseURL(3) function. Relevant code from src/usr.bin/fetch/fetch.c: 312 static int 313 fetch(char *URL, const char *path) 314 { 315 struct url *url; ... 342 /* parse URL */ 343 if ((url = fetchParseURL(URL)) == NULL) { 344 warnx("%s: parse error", URL); 345 goto failure; 346 } The man page for fetchParseURL(3) claims: fetchParseURL() takes a URL in the form of a null-terminated string and splits it into its components function according to the Common Internet Scheme Syntax detailed in RFC1738. A regular expression which produces this syntax is: :(//((:)?@)?(:)?)?/()? If the URL does not seem to begin with a scheme name, the following syn- tax is assumed: (((:)?@)?(:)?)?/()? ..... fetchParseURL() returns a pointer to a struct url containing the individ- ual components of the URL. If it is unable to allocate memory, or the URL is syntactically incorrect, fetchParseURL() returns a NULL pointer. If we add some debugging code *before* the "scheme assumption" portion of fetch.c (which actually looks at the hostname portion and if it starts with "ftp" assumes the scheme is FTP, "http" = HTTP, etc.): 348 printf("fetchParseURL() successful. struct details:\n"); 349 printf("url->scheme = %s\n", url->scheme); 350 printf("url->user = %s\n", url->user); 351 printf("url->pwd = %s\n", url->pwd); 352 printf("url->host = %s\n", url->host); 353 printf("url->port = %d\n", url->port); 354 printf("url->doc = %s\n", url->doc); ...we end up with this: $ ./fetch http:/www.daemonfun.com/ fetchParseURL() successful. struct details: url->scheme = http url->user = url->pwd = url->host = url->port = 0 url->doc = /www.daemonfun.com/ fetch: http:/www.daemonfun.com/: No address record Here we can see the libfetch code properly works out the scheme (URI) on its own (which means the "assumption part" of the man page should not play a role here) -- but incorrectly parses the remaining portion of the URL. In this situation, fetchParseURL(3) should return NULL. The code in fetch.c continues on to call fetchXGet(3) with the above struct data (some of it gets modified, but that's besides the point), and the result is fetchXGet(3) returning NULL (indicating the fetch failed in some way), which gets us here: 463 f = fetchXGet(url, &us, flags); ... 468 if (f == NULL) { 469 warnx("%s: %s", URL, fetchLastErrString); 470 if (i_flag && strcmp(url->scheme, SCHEME_HTTP) == 0 471 && fetchLastErrCode == FETCH_OK 472 && strcmp(fetchLastErrString, "Not Modified") == 0) { 473 /* HTTP Not Modified Response, return OK. */ 474 r = 0; 475 goto done; 476 } else 477 goto failure; 478 } We modify some code to add some debugging to validate that warnx() is what's returning the error message: 469 warnx("fetchXGet() returned NULL: %s: %s", URL, fetchLastErrString); ...and we end up with: fetch: fetchXGet() returned NULL: http:/www.daemonfun.com/: No address record I guess I'll be the one to file the PR. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From marka at isc.org Tue Nov 24 21:14:40 2009 From: marka at isc.org (Mark Andrews) Date: Tue Nov 24 21:14:47 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: Your message of "Tue, 24 Nov 2009 16:53:35 +0200." <86aayc7z4g.fsf@zhuzha.ua1> References: <86aayc7z4g.fsf@zhuzha.ua1> Message-ID: <200911242114.nAOLEZIN049990@drugs.dv.isc.org> Report it using "send-pr". That way the problem will make its way into the bug tracking system. In message <86aayc7z4g.fsf@zhuzha.ua1>, Mikolaj Golub writes: > Hi, > > I have problems with compiling our application under 8.0. > > It fails due to these definitions in pthread.h that look like a typo or > incorrectly applied patch: > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) > \ > 171 { > \ > 172 struct _pthread_cleanup_info __cleanup_info__; > \ > 173 __pthread_cleanup_push_imp(cleanup_routine, clean > up_arg,\ > 174 &__cleanup_info__); > \ > 175 { > 176 > 177 #define pthread_cleanup_pop(execute) > \ > 178 } > \ > 179 __pthread_cleanup_pop_imp(execute); > \ > 180 } > > > This patch fixes the problem for me: > > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > @@ -172,10 +172,10 @@ > struct _pthread_cleanup_info __cleanup_info__; \ > __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg,\ > &__cleanup_info__); \ > - { > + } > > #define pthread_cleanup_pop(execute) > \ > - } \ > + { \ > __pthread_cleanup_pop_imp(execute); \ > } > > -- > Mikolaj Golub > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From deischen at freebsd.org Tue Nov 24 21:29:35 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Tue Nov 24 21:29:43 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <200911242114.nAOLEZIN049990@drugs.dv.isc.org> References: <86aayc7z4g.fsf@zhuzha.ua1> <200911242114.nAOLEZIN049990@drugs.dv.isc.org> Message-ID: On Wed, 25 Nov 2009, Mark Andrews wrote: > > Report it using "send-pr". That way the problem will make its way into the > bug tracking system. > > In message <86aayc7z4g.fsf@zhuzha.ua1>, Mikolaj Golub writes: >> Hi, >> >> I have problems with compiling our application under 8.0. >> >> It fails due to these definitions in pthread.h that look like a typo or >> incorrectly applied patch: Did someone already reply to this? I think the problem is in your application. You cannot have push and pop at different nesting levels. The start brace in the push is ended by the end brace in pop on purpose. It is to enforce nesting levels. >> >> 170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg) >> \ >> 171 { >> \ >> 172 struct _pthread_cleanup_info __cleanup_info__; >> \ >> 173 __pthread_cleanup_push_imp(cleanup_routine, clean >> up_arg,\ >> 174 &__cleanup_info__); >> \ >> 175 { >> 176 >> 177 #define pthread_cleanup_pop(execute) >> \ >> 178 } >> \ >> 179 __pthread_cleanup_pop_imp(execute); >> \ >> 180 } -- DE From marka at isc.org Tue Nov 24 21:41:14 2009 From: marka at isc.org (Mark Andrews) Date: Tue Nov 24 21:41:21 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: Your message of "Tue, 24 Nov 2009 17:34:22 +0200." <20091124153422.GT2331@deviant.kiev.zoral.com.ua> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> Message-ID: <200911242141.nAOLfAQa050429@drugs.dv.isc.org> In message <20091124153422.GT2331@deviant.kiev.zoral.com.ua>, Kostik Belousov write s: > > --i616tqyc3hrkKsk2 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: > > On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote: > >=20 > > > Hi, > > > > > > I have problems with compiling our application under 8.0. > > > > > > It fails due to these definitions in pthread.h that look like a typo or > > > incorrectly applied patch: > > > > > > 170 #define pthread_cleanup_push(cleanup_routine, cleanup_a= > rg) \ > > > 171 { = > \ > > > 172 struct _pthread_cleanup_info __cleanup_= > info__; \ > > > 173 __pthread_cleanup_push_imp(cleanup_rout= > ine, cleanup_arg,\ > > > 174 &__cleanup_info__); = > \ > > > 175 { > > > 176=20 > > > 177 #define pthread_cleanup_pop(execute) = > \ > > > 178 } = > \ > > > 179 __pthread_cleanup_pop_imp(execute); = > \ > > > 180 } > > > > > > > > > This patch fixes the problem for me: > >=20 > > I was hurry when said that the patch fixed the problem. The application > > compiled but later it crashed in pthread_cleanup_pop: > >=20 > > (gdb) bt > > #0 0xbf4f9ee0 in ?? () > > #1 0x287d18c9 in __pthread_cleanup_pop_imp () from /lib/libthr.so.3 > > #2 0x287d18ed in pthread_cleanup_pop () from /lib/libthr.so.3 > > #3 0x287d123c in pthread_exit () from /lib/libthr.so.3 > > #4 0x287c7757 in pthread_getprio () from /lib/libthr.so.3 > > #5 0x00000000 in ?? () > >=20 > > So, I don't know what these macros actually were supposed to be. They were > > introduced in r179662: > >=20 > > Revision 1.43: download - view: text, markup, annotated - select for diffs > > Mon Jun 9 01:14:10 2008 UTC (17 months, 2 weeks ago) by davidxu > > Branches: MAIN > > Diff to: previous 1.42: preferred, colored > > Changes since revision 1.42: +21 -2 lines > >=20 > > SVN rev 179662 on 2008-06-09 01:14:10Z by davidxu > >=20 > > Make pthread_cleanup_push() and pthread_cleanup_pop() as a pair of macros, > > use stack space to keep cleanup information, this eliminates overhead of > > calling malloc() and free() in thread library. > >=20 > > Discussed on: thread@ > >=20 > > > --- pthread.h.orig 2009-11-24 16:44:13.000000000 +0200 > > > +++ pthread.h 2009-11-24 16:44:45.000000000 +0200 > > > @@ -172,10 +172,10 @@ > > > struct _pthread_cleanup_info __cleanup_info__; = > \ > > > __pthread_cleanup_push_imp(cleanup_routine, cle= > anup_arg,\ > > > &__cleanup_info__); = > \ > > > - { > > > + } =20 > > > =20 > > > #define pthread_cleanup_pop(execute) = > \ > > > - } = > \ > > > + { = > \ > > > __pthread_cleanup_pop_imp(execute); = > \ > > > } > > pthread_cleanup_push/pop are supposed to be used from the common > lexical scope. Citation from SUSv4: > > These functions may be implemented as macros. The application shall > ensure that they appear as statements, and in pairs within the same > lexical scope (that is, the pthread_cleanup_push() macro may be > thought to expand to a token list whose first token is '{' with > pthread_cleanup_pop() expanding to a token list whose last token is the > corresponding '}' ). > > Your change is wrong. > > Basically, the code should do > pthread_cleanup_push(some_func, arh); > something ... > pthread_cleanup_pop(1); > (1 denotes that some_func should be called). The problem is that that expands to C code that can only be used with newer C compilers. This expansion should be usable with all C compilers. #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ { \ struct _pthread_cleanup_info __cleanup_info__; \ __pthread_cleanup_push_imp(cleanup_routine, cleanup _arg,\ &__cleanup_info__) #define pthread_cleanup_pop(execute) \ __pthread_cleanup_pop_imp(execute); \ } ((void)0) > > --i616tqyc3hrkKsk2 > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (FreeBSD) > > iEYEARECAAYFAksL/P4ACgkQC3+MBN1Mb4h4UwCgxIIHVqHBqU9wPIQKiOWf9g2z > r94AoOiN4CE6Eig6AlJ1IuHFo9Hk7Pvf > =FjUi > -----END PGP SIGNATURE----- > > --i616tqyc3hrkKsk2-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pluknet at gmail.com Tue Nov 24 21:53:28 2009 From: pluknet at gmail.com (pluknet) Date: Tue Nov 24 21:53:34 2009 Subject: [geom] page fault in g_mbr_config() In-Reply-To: References: Message-ID: 2009/7/24 pluknet : > 2009/7/24 pluknet : >> Hi. >> >> I got a panic while performing a repetitive ?'fdisk -BI aacd0', >> where aacd0 is a disk on aac0: . >> This means that the command was issued after filesystems >> were already created on aacd (after the first fdisk -BI aacd0 >> iteration), and are in umount'ed state. >> >> This is on 7.2-R, amd64. Config is a GENERIC plus ddb, carp, ipfw, quota. >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 5; apic id = 05 >> fault virtual address ? = 0x20 >> fault code ? ? ? ? ? ? ?= supervisor read data, page not present >> instruction pointer ? ? = 0x8:0xffffffff804cc554 >> stack pointer ? ? ? ? ? = 0x10:0xfffffffe80079b80 >> frame pointer ? ? ? ? ? = 0x10:0xfffffffe80079bd0 >> code segment ? ? ? ? ? ?= base 0x0, limit 0xfffff, type 0x1b >> ? ? ? ? ? ? ? ? ? ? ? ?= DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags ? ? ? ?= interrupt enabled, resume, IOPL = 0 >> current process ? ? ? ? = 2 (g_event) >> [thread pid 2 tid 100013 ] >> Stopped at ? ? ?g_mbr_config+0x64: ? ? ?movq ? ?0x20(%rax),%r15 >> db> bt >> Tracing pid 2 tid 100013 td 0xffffff000144da50 >> g_mbr_config() at g_mbr_config+0x64 >> g_run_events() at g_run_events+0x1b8 >> g_event_procbody() at g_event_procbody+0x57 >> fork_exit() at fork_exit+0x11f >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xfffffffe80079d30, rbp = 0 --- > > And, of course... > > db> show proc 818 > Process 818 (fdisk) at 0xffffff0004ed1000: > ?state: NORMAL > ?uid: 0 ?gids: 0, 0, 5 > ?parent: pid 814 at 0xffffff00045c0478 > ?ABI: FreeBSD ELF64 > ?arguments: fdisk > ?threads: 1 > 100169 ? ? ? ? ? ? ? ? ? D ? ? ? g_waitfo 0xffffff0004ec9100 fdisk > db> bt 818 > Tracing pid 818 tid 100169 td 0xffffff0004fbf6e0 > sched_switch() at sched_switch+0x1fe > mi_switch() at mi_switch+0x18e > sleepq_timedwait() at sleepq_timedwait+0x31 > _sleep() at _sleep+0x354 > g_waitfor_event() at g_waitfor_event+0x9a > g_ctl_ioctl() at g_ctl_ioctl+0x2df > giant_ioctl() at giant_ioctl+0x7d > devfs_ioctl_f() at devfs_ioctl_f+0x77 > kern_ioctl() at kern_ioctl+0xa2 > ioctl() at ioctl+0xf9 > syscall() at syscall+0x256 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8008200ec, rsp = > 0x7fffffffe1d8, rbp = 0x4 --- > This makes me tied to GEOM_* -> GEOM_PART_* scheme (which is in 8+ in DEFAULTS now). After this replacement in DEFAULTS I see no more panics in 'fdisk -BI aacd0'. -- wbr, pluknet From zbeeble at gmail.com Tue Nov 24 22:11:58 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Tue Nov 24 22:12:05 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> Message-ID: <5f67a8c40911241411l95e06ebya99270ac4eff17e3@mail.gmail.com> On Sun, Nov 22, 2009 at 11:47 PM, Zaphod Beeblebrox wrote: > > > On Sun, Nov 22, 2009 at 9:09 PM, Zaphod Beeblebrox wrote: > >> >> >> On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick < >> freebsd@jdc.parodius.com> wrote: >> >>> >>> > This 1950 may predate that a bit, but I'm not sure how to nail it down >>> > exactly, other than by it's hardware components. Anyways, 7.0 does the >>> same >>> > thing --- still wedged. >>> >>> I haven't seen anyone recommend this as a test method yet -- disabling >>> fdc prior to the kernel booting via the loader prompt: >>> >>> - Press 6 at the menu, >>> - At the loader prompt, type: >>> >>> set hint.fdc.0.disabled="1" >>> boot -v (or without -v; your choice) >>> >>> You shouldn't need to set hint.fd.0.disabled="1", since fd0 would >>> normally bind to fdc0; disable the latter and you disable the lesser. >>> >>> The intention here is to rule out the device attachment failures from >>> fdc as the source of the deadlock. >>> >> >> Entertainingly, it does not. Aparently that hint doesn't stop the code >> from trying to attach fdc0 when acpi says so. I suppose I need to know the >> console command to disable acpi and fdc. >> >> but it still wedges at "device_attach: fdc0 attach returned 6" with the >> above. >> >> > OK. With both floppy and acpi disabled, it dies calling "start_init" > several times, the last being /stand/sysinstal (which should work). I don't > see it "starting" the other CPUs. It hangs hard... no keyboard working (ie: > no caps lock). > > OK... I finally figured out what makes this Dell boot. The system as I got it has 2 dual core (Xeon) processors. If I remove one processor (so now it has one dual-core processor), Then the system boots !?! ... so there's something wrong with how FreeBSD is going multiprocessor (works with RedHat, it would appear) From deischen at freebsd.org Tue Nov 24 22:20:27 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Tue Nov 24 22:20:35 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: <200911242141.nAOLfAQa050429@drugs.dv.isc.org> References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> <200911242141.nAOLfAQa050429@drugs.dv.isc.org> Message-ID: On Wed, 25 Nov 2009, Mark Andrews wrote: > > In message <20091124153422.GT2331@deviant.kiev.zoral.com.ua>, Kostik Belousov write > s: >> >> --i616tqyc3hrkKsk2 >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: >> >> pthread_cleanup_push/pop are supposed to be used from the common >> lexical scope. Citation from SUSv4: >> >> These functions may be implemented as macros. The application shall >> ensure that they appear as statements, and in pairs within the same >> lexical scope (that is, the pthread_cleanup_push() macro may be >> thought to expand to a token list whose first token is '{' with >> pthread_cleanup_pop() expanding to a token list whose last token is the >> corresponding '}' ). >> >> Your change is wrong. >> >> Basically, the code should do >> pthread_cleanup_push(some_func, arh); >> something ... >> pthread_cleanup_pop(1); >> (1 denotes that some_func should be called). > > The problem is that that expands to C code that can only be used > with newer C compilers. This expansion should be usable with all > C compilers. > > #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \ > { \ > struct _pthread_cleanup_info __cleanup_info__; \ > __pthread_cleanup_push_imp(cleanup_routine, cleanup _arg,\ > &__cleanup_info__) > > #define pthread_cleanup_pop(execute) \ > __pthread_cleanup_pop_imp(execute); \ > } ((void)0) Hmm, agreed. But note that Solaris 10 does it this way: #define pthread_cleanup_push(routine, args) { \ _cleanup_t _cleanup_info; \ __pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \ (caddr_t)_getfp(), &_cleanup_info); #define pthread_cleanup_pop(ex) \ __pthread_cleanup_pop(ex, &_cleanup_info); \ } -- DE From marka at isc.org Tue Nov 24 22:30:25 2009 From: marka at isc.org (Mark Andrews) Date: Tue Nov 24 22:30:31 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: Your message of "Tue, 24 Nov 2009 17:20:25 CDT." References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> <200911242141.nAOLfAQa050429@drugs.dv.isc.org> Message-ID: <200911242230.nAOMUKmh052215@drugs.dv.isc.org> In message , Daniel Eischen wri tes: > On Wed, 25 Nov 2009, Mark Andrews wrote: > > > > > In message <20091124153422.GT2331@deviant.kiev.zoral.com.ua>, Kostik Belous > ov write > > s: > >> > >> --i616tqyc3hrkKsk2 > >> Content-Type: text/plain; charset=us-ascii > >> Content-Disposition: inline > >> Content-Transfer-Encoding: quoted-printable > >> > >> On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote: > >> > >> pthread_cleanup_push/pop are supposed to be used from the common > >> lexical scope. Citation from SUSv4: > >> > >> These functions may be implemented as macros. The application shall > >> ensure that they appear as statements, and in pairs within the same > >> lexical scope (that is, the pthread_cleanup_push() macro may be > >> thought to expand to a token list whose first token is '{' with > >> pthread_cleanup_pop() expanding to a token list whose last token is the > >> corresponding '}' ). > >> > >> Your change is wrong. > >> > >> Basically, the code should do > >> pthread_cleanup_push(some_func, arh); > >> something ... > >> pthread_cleanup_pop(1); > >> (1 denotes that some_func should be called). > > > > The problem is that that expands to C code that can only be used > > with newer C compilers. This expansion should be usable with all > > C compilers. > > > > #define pthread_cleanup_push(cleanup_routine, cleanup_arg) > \ > > { \ > > struct _pthread_cleanup_info __cleanup_info__; \ > > __pthread_cleanup_push_imp(cleanup_routine, cleanup > _arg,\ > > &__cleanup_info__) > > > > #define pthread_cleanup_pop(execute) > \ > > __pthread_cleanup_pop_imp(execute); \ > > } ((void)0) > > Hmm, agreed. But note that Solaris 10 does it this way: > > #define pthread_cleanup_push(routine, args) { \ > _cleanup_t _cleanup_info; \ > __pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \ > (caddr_t)_getfp(), &_cleanup_info); > > #define pthread_cleanup_pop(ex) \ > __pthread_cleanup_pop(ex, &_cleanup_info); \ > } Writing portable macros that don't generate compiler warnings is fun. :-) Tricks like "do { } while (0)" and "{ } ((void)0)" absorb the pesky semi-colon. > -- > DE -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From gjin at ubicom.com Tue Nov 24 23:09:41 2009 From: gjin at ubicom.com (Guojun Jin) Date: Tue Nov 24 23:09:48 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: References: <200911221047.20362.hselasky@c2i.net> Message-ID: Interesting now by some incident :-) The single CPU machine (Intel P4) with 8.0 works fine on the USB drives and the USB stick. So, installed 8.0 on another AMD Turion64 HP Pavilion dv5210us Laptop, it comes the same problem -- accessing the USB hard drive causes system panic and reboot: Took the previously dump/restored USB drive and mount it on this Laptop, tried to remove the data before dump/restore, it crashed the system after hit ^C and unplugged USB hard drive when the LED on USB hard drive becomes solid red and spiting out numbers of lines Operation not permitted (the user is root, so this means accessing hard drive is not possible): rm: bin/... : Operation not permitted ...... A second try causes the system locks up After ^C. So, try to re-partitioning the USB hard drive on AMD laptop and dump/restore, partitioning passed, but dump/restore crashed. Since hw.usb.umass.debug=-1 does not tell a USB problem beside the RESET, What other debug shall we turn on to analyze this problem. -----Original Message----- From: Guojun Jin Sent: Tuesday, November 24, 2009 12:13 AM To: Guojun Jin; Hans Petter Selasky; freebsd-usb@freebsd.org Cc: bugs@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem Freshly installed 8.0-RELEASE on two differnt machines, and USB stick work well so far, but the USB hard drive still has crash on this SMP (4-core AMD phenom 9600) during the dump/restore. I will try it on the single CPU machine tomorrow. Re-tested dump/restore with FreeBSD 6.3/6.4 on this SMP machine and they are working well. Also the another strange thing ocurred during the mount a partition on /tmp, which ended with two /tmp, and the last one mounted is on the top (the first should be hidden): : df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 756750 165484 530726 24% / devfs 1 1 0 100% /dev /dev/ad0s2e 43194318 27833648 11905126 70% /data /dev/ad0s2d 9135182 5870390 2533978 70% /home /dev/ad0s1e 507630 34882 432138 7% /tmp /dev/ad0s1f 13246730 1424522 10762470 12% /usr /dev/ad0s1d 5077038 12700 4658176 0% /var /dev/da0s2 661176 487660 120622 80% /mnt /dev/da1s3d 9135182 4 8404364 0% /dist /dev/da1s3e 74938948 4 68943830 0% /tmp : df /tmp Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da1s3e 74938948 4 68943830 0% /tmp -----Original Message----- From: Guojun Jin Sent: Sun 11/22/2009 7:59 PM To: Hans Petter Selasky; freebsd-usb@freebsd.org Cc: bugs@freebsd.org; freebsd-stable@freebsd.org Subject: RE: 8.0-RC USB/FS problem >From more intensive diagnose, it looks like more related USB layer. repeated a few time on following process and ithe crash happened at different USB access phase at each time. dd if=/dev/zero of=/dev/da0 count=1000 bs=4k sysinstall partition slice 1 (da0s1) 18GB ID=12 slice 2 (da0s2) 10-15GB Id=165 slice 3 (da0s3) rest ID=165 W ---> OK label da0s3d 9GB /mnt da0s3e rest /dist W ---> da0s3e ---- device is not configured. w# ll /dev/da0* # after sysinstall did partition + W at 1st time crw-r----- 1 root operator 0, 97 Nov 22 11:23 /dev/da0 crw-r----- 1 root operator 0, 98 Nov 22 11:23 /dev/da0s1 crw-r----- 1 root operator 0, 99 Nov 22 11:23 /dev/da0s2 crw-r----- 1 root operator 0, 100 Nov 22 11:23 /dev/da0s3 # ll /dev/da0* # after sysinstall start at 2nd time crw-r----- 1 root operator 0, 97 Nov 22 11:27 /dev/da0 System crashed The crash log is available at http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2 (All logs are based on hw.usb.umass.debug=-1) After system reboot, and repeated above processes, the da0s3e was mounted on /dist, but da0s3d cannot. It tunred out that newfs fail inside labeling process in sysinstall. Manually did newfs on da0s3d, and it cannot be mounted on /mnt, but access to it caused crash. The crash log is available at http:/www.daemonfun.com/archives/pub/USB/newfs Tried entire process again, this time, both partitons are formatted (newfs) inside labaling process (sysinstall) but crahsed system during dump/restore on da0s3e (/dist). The crash log is available at http:/www.daemonfun.com/archives/pub/USB/usb-log.crash2.bz2, which is huge one. It contains two parts, one dump/restore IDE to da0s3d (passed), and the rest is dump/restore to da0s3e (crashed). I am going to reinstall the system with the new ISO from Nov 21 8.0-RELEASE to see if anything will improve. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Sun 11/22/2009 1:47 AM To: freebsd-usb@freebsd.org Cc: Guojun Jin; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Sunday 22 November 2009 05:38:13 Guojun Jin wrote: > Tried on the USB hard drive: > > Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e. > Was happy because successfully did dump/restore on s3d, and thought it just > partition format issue; but system crashed during dump/restore on s3e, and > partition lost the file system type. > > wolf# mount /dev/da0s3e /mnt > WARNING: /mnt was not properly dismounted > /mnt: mount pending error: blocks 35968 files 0 > wolf# fsck da0s3e > fsck: Could not determine filesystem type > wolf# bsdlabel da0s3 > # /dev/da0s3: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 175735035 0 unused 0 0 # "raw" part, > don't edi t > d: 18874368 0 4.2BSD 0 0 0 > e: 156860667 18874368 4.2BSD 0 0 0 > > Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick > to get file system clean up. All data got back now. > > The machine has run with FreeBSD 6.1 all the way to 7.2 without such > problem. How can we determine what could go wrong in 8.0? FS or USB. Hi, Error 5 means IO error, so probably the transport layer, USB or lower, is to blame. Some things to check: 1) Make sure the connection for your memory stick is Ok. 2) Make sure there is enough power for your memory stick. Regarding memory sticks: Other operating systems do a port bus reset when the device has a problem. On FreeBSD we just try a software reset via the control endpoint. I guess that it is a device problem you are seeing. The USB stack in FreeBSD is faster than the old one, and maybe the faster queueing of mass storage requests trigger some hidden bugs in your device. When the problem happens try: sysctl hw.usb.umass.debug=-1 --HPS From dwilde1 at gmail.com Wed Nov 25 00:14:22 2009 From: dwilde1 at gmail.com (Don Wilde) Date: Wed Nov 25 00:14:29 2009 Subject: sackcloth and ashes time Message-ID: Dear FreeBSD friends; I recently added my gmail contacts to Linked-In, Inviting only those who were already on Linked-In, and discovered -- thanks to Bruce Cran -- that it came to STABLE. Looking in Linked-In at his profile, Mr Rotaev's public e-mail address address is clearly noted as being freebsd-stable@freebsd.org. I have requested that Linked-In customer service address the matter, as I cannot contact him without causing more of the same spam in your mailboxes. He does not appear to be an active Linked-In user. Thank you all in advance for your understanding! :D -- -- Don Wilde " Convince by Example " http://www.EngineeringJobFuture.com From davidxu at freebsd.org Wed Nov 25 01:56:37 2009 From: davidxu at freebsd.org (David Xu) Date: Wed Nov 25 01:56:44 2009 Subject: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop In-Reply-To: References: <86aayc7z4g.fsf@zhuzha.ua1> <8663907xyy.fsf@zhuzha.ua1> <20091124153422.GT2331@deviant.kiev.zoral.com.ua> <200911242141.nAOLfAQa050429@drugs.dv.isc.org> Message-ID: <4B0C8ED2.7030101@freebsd.org> Daniel Eischen wrote: > Hmm, agreed. But note that Solaris 10 does it this way: > > #define pthread_cleanup_push(routine, args) { \ > _cleanup_t _cleanup_info; \ > __pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \ > (caddr_t)_getfp(), &_cleanup_info); > > #define pthread_cleanup_pop(ex) \ > __pthread_cleanup_pop(ex, &_cleanup_info); \ > } > Hmm, I considered using this style, but if there is a C++ object within the lexical scope, its destructor will execute after pthread_cleanup_pop(), this may not be correct, so I used extra pair of '{}'. From hselasky at c2i.net Wed Nov 25 08:35:34 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Nov 25 08:35:52 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: References: Message-ID: <200911250937.08267.hselasky@c2i.net> On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote: > What other debug shall we turn on to analyze this problem. Are you able to extract the panic message? Try enabling dump on the swap partition. --HPS From rpalov at e-card.bg Wed Nov 25 11:34:27 2009 From: rpalov at e-card.bg (=?windows-1252?Q?=3F=3F=3F=3F=3F_=3F=3F=3F=3F=3F?=) Date: Wed Nov 25 11:34:35 2009 Subject: FreeBSD 7.x hang-on-boot on Dell 1950 In-Reply-To: <5f67a8c40911241411l95e06ebya99270ac4eff17e3@mail.gmail.com> References: <5f67a8c40911121246m144ba07w707a1c268fb2102c@mail.gmail.com> <4AFD6D69.7090109@thekeelecentre.com> <5f67a8c40911131757s48a57d9by11c74a417324e48c@mail.gmail.com> <20091114024438.GA93630@icarus.home.lan> <5f67a8c40911221809h25253009od8a83d058f68ad9c@mail.gmail.com> <5f67a8c40911222047m78ac7378i8a2016449d0d2996@mail.gmail.com> <5f67a8c40911241411l95e06ebya99270ac4eff17e3@mail.gmail.com> Message-ID: <4B0D0FEC.60409@e-card.bg> Hi all, I have dell 1950 / Single Xeon , 8G RAM , SAS Host without RAID / im my hands. Yesterday we have install FreeBSD7.2 AMD. After INITIAL install all works fine and next step was cvsup & base & kernel rebuild. This steps are also fine BUT after first reboot from SINGLE mode to MULTIUSER mode the system has the same strange behavior, like described in this thread: Very slow passed boot init on fdc0 and it has very very slow and strange responce in text consloe switching. So the server was inusable. Next step was to shutdown the server from power button and just boot-up again and it .. was fine: fdc0 is reported like this: "fdc0: does not respond" for less a second and normal booting processed is goin on. The server is working well and stable now. Zaphod Beeblebrox wrote: > On Sun, Nov 22, 2009 at 11:47 PM, Zaphod Beeblebrox wrote: > >> >> On Sun, Nov 22, 2009 at 9:09 PM, Zaphod Beeblebrox wrote: >> >>> >>> On Fri, Nov 13, 2009 at 9:44 PM, Jeremy Chadwick < >>> freebsd@jdc.parodius.com> wrote: >>> >>>>> This 1950 may predate that a bit, but I'm not sure how to nail it down >>>>> exactly, other than by it's hardware components. Anyways, 7.0 does the >>>> same >>>>> thing --- still wedged. >>>> I haven't seen anyone recommend this as a test method yet -- disabling >>>> fdc prior to the kernel booting via the loader prompt: >>>> >>>> - Press 6 at the menu, >>>> - At the loader prompt, type: >>>> >>>> set hint.fdc.0.disabled="1" >>>> boot -v (or without -v; your choice) >>>> >>>> You shouldn't need to set hint.fd.0.disabled="1", since fd0 would >>>> normally bind to fdc0; disable the latter and you disable the lesser. >>>> >>>> The intention here is to rule out the device attachment failures from >>>> fdc as the source of the deadlock. >>>> >>> Entertainingly, it does not. Aparently that hint doesn't stop the code >>> from trying to attach fdc0 when acpi says so. I suppose I need to know the >>> console command to disable acpi and fdc. >>> >>> but it still wedges at "device_attach: fdc0 attach returned 6" with the >>> above. >>> >>> >> OK. With both floppy and acpi disabled, it dies calling "start_init" >> several times, the last being /stand/sysinstal (which should work). I don't >> see it "starting" the other CPUs. It hangs hard... no keyboard working (ie: >> no caps lock). >> >> OK... I finally figured out what makes this Dell boot. The system as I got > it has 2 dual core (Xeon) processors. > > If I remove one processor (so now it has one dual-core processor), Then the > system boots !?! > > ... so there's something wrong with how FreeBSD is going multiprocessor > (works with RedHat, it would appear) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From dsh at wizard.volgograd.ru Wed Nov 25 12:00:11 2009 From: dsh at wizard.volgograd.ru (Denis Shaposhnikov) Date: Wed Nov 25 12:00:20 2009 Subject: how to disable APM using camcontrol cmd Message-ID: <20091125145523.6420d4a5@wizard.volgograd.ru> Hello, I'm trying to replace sysutils/ataidle which doesn't work with new acpi(4). May be somebody could tell me args for camcontrol cmd ada0 -a cmd XX XX XX XX XX XX XX XX to disable APM and acoustic management (AAM) for my HDD? Thanks! From npapke at acm.org Wed Nov 25 16:05:16 2009 From: npapke at acm.org (Norbert Papke) Date: Wed Nov 25 16:05:27 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: <20091124174714.GA2240@icarus.home.lan> References: <200911241813.23616.hselasky@c2i.net> <20091124174714.GA2240@icarus.home.lan> Message-ID: <200911250805.14558.npapke@acm.org> On November 24, 2009, Jeremy Chadwick wrote: > $ host www.daemonfun.com > www.daemonfun.com is an alias for daemonfun.com. > daemonfun.com has address 76.202.192.211 > daemonfun.com mail is handled by 10 mh1.daemonfun.com. > daemonfun.com mail is handled by 20 mh2.daemonfun.com. > > $ fetch http:/www.daemonfun.com/ > fetch: http:/www.daemonfun.com/: No address record > > I haven't examined the code, but my guess is fetch is trying to do a > lookup on the FQDN "http:/www.daemonfun.com/". Who wants to file a PR? As Dan Nelson mentioned, it's just a typo in the url. Try $ fetch http://www.daemonfun.com/ Note the "://" rather than ":/". Cheers. -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From bsdlist at cogeco.ca Wed Nov 25 16:09:10 2009 From: bsdlist at cogeco.ca (Paul MacKenzie) Date: Wed Nov 25 16:09:19 2009 Subject: Problem with running 6.X libraries on 7.2 with Apache Message-ID: <4B0D501C.1070702@cogeco.ca> Hello, I have am having a problem which I am fairly sure I have traced to running 6.X based code on 7.2 with apache such as Wusage and Scomtherm. All runs fine on the server without these running and when I start the program the system spirals downwards only on http from what I can tell. It seems to be connected to PHP within apache in part. If I allow the system to run programs needing this code it causes problems with Apache taking 100% of the cpu. When I stop the program from accessing the old libraries the issue does not come back. FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed Jul 1 09:36:28 EDT 2009 amd64 Apache setup: apache-2.2.13 TOP when the system has the problem visible: last pid: 1824; load averages: 207.55, 91.64, 38.50 up 7+11:03:23 08:55:20 755 processes: 236 running, 516 sleeping, 3 lock CPU: 11.2% user, 0.0% nice, 86.7% system, 2.0% interrupt, 0.1% idle Mem: 5617M Active, 8371M Inact, 1179M Wired, 244M Cache, 399M Buf, 433M Free Swap: 8192M Total, 648K Used, 8191M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1730 www 1 61 0 197M 41004K RUN 2 0:06 4.59% httpd 1475 www 1 -4 0 195M 39220K ufs 7 0:06 4.49% httpd 1732 www 1 -4 0 193M 38124K RUN 0 0:06 4.39% httpd 1651 www 1 -4 0 221M 59520K RUN 0 0:07 4.20% httpd 1653 www 1 -4 0 220M 59244K RUN 0 0:07 3.96% httpd 1609 www 1 -4 0 227M 64656K RUN 6 0:07 3.96% httpd 1431 www 1 -4 0 220M 59804K RUN 6 0:13 3.86% httpd 1568 www 1 -4 0 195M 39288K RUN 6 0:09 3.86% httpd 1572 www 1 -4 0 222M 61052K RUN 0 0:09 3.86% httpd 1585 www 1 -4 0 227M 64844K RUN 5 0:07 3.86% httpd 1681 www 1 64 0 220M 59368K RUN 3 0:07 3.86% httpd 1738 www 1 64 0 197M 40772K RUN 7 0:05 3.86% httpd 1648 www 1 67 0 210M 50628K RUN 6 0:08 3.76% httpd 1600 www 1 60 0 221M 59632K RUN 7 0:08 3.76% httpd 1622 www 1 -4 0 220M 59216K RUN 5 0:08 3.76% httpd 1619 www 1 -4 0 220M 58768K RUN 2 0:07 3.76% httpd I wondered if anyone else has had a similar problem or might be able to suggest a way to fix this? I am going to try an upgrade to the latest 7.2 shortly. Thanks, Paul From rmacklem at uoguelph.ca Wed Nov 25 16:15:55 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Wed Nov 25 16:16:02 2009 Subject: zfs/nfs mkstemp() failure & subsequent hangs In-Reply-To: <20091120132945.e2031bfb.gerrit@pmp.uni-hannover.de> References: <20091120132945.e2031bfb.gerrit@pmp.uni-hannover.de> Message-ID: On Fri, 20 Nov 2009, Gerrit Kühn wrote: > Hi all, > > I have a 8.0-PRERELEASE zfs/nfs server here that complains about i/o > errors when using rsync on a nfs client: > > rsync: mkstemp > "/usr/portage/metadata/cache/app-mobilephone/.ksms-0.1.2.4.BynVFw" failed: > Input/output error (5) > > > I found this to be quite similar to kern/135412. However, this one > is said to be fixed and only applicable to 7-stable anyway. > Furthermore, after this happened, I tried to access files on the server > from the zfs filesystem concerned and found that I cannot access the fs > anymore. ls hangs in state zfs, so do mountd and zfs unmount. > > Questions: > Should I open a new PR for this? Gerrit reports that the fix recently committed to FreeBSD-current as r199616 (and will be MFC'd to stable/8 in about 2 weeks unless problems with it are reported) has fixed this problem. Thanks to Gerrit for reporting it and testing the fix, rick From gjin at ubicom.com Wed Nov 25 17:42:35 2009 From: gjin at ubicom.com (Guojun Jin) Date: Wed Nov 25 17:42:52 2009 Subject: 8.0-RC USB/FS problem References: <200911250937.08267.hselasky@c2i.net> Message-ID: I will do, I also borrowed two other machiens -- one AMD two core laptop, and one P4 desktop -- for further testing. I will enable kernel coredump for all of them and will make cores available by end of today. -Jin -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/25/2009 12:37 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote: > What other debug shall we turn on to analyze this problem. Are you able to extract the panic message? Try enabling dump on the swap partition. --HPS From glen.j.barber at gmail.com Thu Nov 26 02:47:10 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Thu Nov 26 02:47:46 2009 Subject: [panic] 8.0-PRERELEASE Message-ID: Hello, This evening I experienced another panic on a Toshiba laptop on which I've been having excessive hang-up issues. This time, I was able to get a crash report (attached, with fstat output excluded because of the length). Any thoughts? -- Glen Barber -------------- next part -------------- A non-text attachment was scrubbed... Name: core.txt.5 Type: application/octet-stream Size: 68808 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091126/c86dbdce/core.txt.obj From randy at psg.com Thu Nov 26 06:18:11 2009 From: randy at psg.com (Randy Bush) Date: Thu Nov 26 06:18:19 2009 Subject: 5.5-STABLE to 88.0-RELEASE Message-ID: can one go from 5.5 to 8.0 using the normal hammer, or is it multi-stage, and i should just blow it away and go from install? randy From gjin at ubicom.com Thu Nov 26 07:35:05 2009 From: gjin at ubicom.com (Guojun Jin) Date: Thu Nov 26 07:35:14 2009 Subject: 8.0-RC USB/FS problem References: <200911250937.08267.hselasky@c2i.net> Message-ID: Most crash had the same back trace. This is also true when USB access hangs, then unplug the drive. More interesting is the third AMD laptop (dual core) had similar problem, but it is less crashing but hanging. The core information is available at the same place (bt file is also attached): http://www.daemonfun.com/archives/public/USB -rw-r--r-- 1 jin wheel 4668 Nov 25 23:17 bt -rw------- 1 4294967294 wheel 80074 Nov 25 22:59 core.txt.0 -rw-r--r-- 1 4294967294 wheel 72108588 Nov 25 23:09 coredump-0.tbz core.txt.0 is from savecore, and bt is I did back trace so it has slightly more information than core.txt. The tbz file contains the kernel.symbol and all files from savecore. I will continute to dig this and I will set more coredump if new crash happens at different place. Please let me know anything I can help debug futher before Dec 3rd. I will on travel for a while and I do not want to hold release for another two weeks. So let's resolve the problem before I am on travel if possible. -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/25/2009 12:37 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote: > What other debug shall we turn on to analyze this problem. Are you able to extract the panic message? Try enabling dump on the swap partition. --HPS -------------- next part -------------- A non-text attachment was scrubbed... Name: bt Type: application/octet-stream Size: 4450 bytes Desc: bt Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091126/809e803e/bt-0001.obj From arnaud.houdelette at tzim.net Thu Nov 26 08:22:18 2009 From: arnaud.houdelette at tzim.net (Arnaud Houdelette) Date: Thu Nov 26 08:22:25 2009 Subject: Can't use gpt labels re-importing pool Message-ID: <4B0E3ABA.3030606@tzim.net> I just upgraded from 7.2 to 8.0. Under 7.2 the pool was like : NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6p1 ONLINE 0 0 0 ad10p1 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 ad4p1 ONLINE 0 0 0 I'd like to use gpt labels or gptids reimporting the pool. # ls /dev/gpt disk1 disk2 disk3 disk4 # ls /dev/gptid 0902db4e-d462-11de-96bd-001d923bc7a0 9fb111f8-d426-11de-99bc-001d923bc7a0 1be29091-d9dc-11de-9f4a-001d923bc7a0 ffb4e96a-d497-11de-96bd-001d923bc7a0 I did # zpool import -d /dev/gpt tank and I got tank ONLINE raidz1 ONLINE ada1p1 ONLINE ada3p1 ONLINE ada2p1 ONLINE gpt/disk4 ONLINE Now, how to force zpool import to only use gpt labels (or uuids) ? Or at least get back to coherent situation ( zpool export tank / zpool import gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid gives nothing ) ? Thanks in advance. Arnaud From swhetzel at gmail.com Thu Nov 26 08:40:18 2009 From: swhetzel at gmail.com (Scot Hetzel) Date: Thu Nov 26 08:40:24 2009 Subject: Can't use gpt labels re-importing pool In-Reply-To: <4B0E3ABA.3030606@tzim.net> References: <4B0E3ABA.3030606@tzim.net> Message-ID: <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> On 11/26/09, Arnaud Houdelette wrote: > I just upgraded from 7.2 to 8.0. > Under 7.2 the pool was like : > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad6p1 ONLINE 0 0 0 > ad10p1 ONLINE 0 0 0 > ad8p1 ONLINE 0 0 0 > ad4p1 ONLINE 0 0 0 > > I'd like to use gpt labels or gptids reimporting the pool. > # ls /dev/gpt > disk1 disk2 disk3 disk4 > # ls /dev/gptid > 0902db4e-d462-11de-96bd-001d923bc7a0 > 9fb111f8-d426-11de-99bc-001d923bc7a0 > 1be29091-d9dc-11de-9f4a-001d923bc7a0 > ffb4e96a-d497-11de-96bd-001d923bc7a0 > > I did # zpool import -d /dev/gpt tank > and I got > tank ONLINE > raidz1 ONLINE > ada1p1 ONLINE > ada3p1 ONLINE > ada2p1 ONLINE > gpt/disk4 ONLINE > > Now, how to force zpool import to only use gpt labels (or uuids) ? Or at > least get back to coherent situation ( zpool export tank / zpool import > gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid > gives nothing ) ? > Use 'zpool replace' to change the zfs pool to use the gpt names: zpool replace tank ada1p1 gpt/disk1 zpool replace tank ada2p1 gpt/disk2 zpool replace tank ada3p1 gpt/disk3 NOTE: make sure you use the correct gpt names for each partition, as the above assumes that ada1p1 is labeled as disk1. Scot From freebsd at jdc.parodius.com Thu Nov 26 08:50:37 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Nov 26 08:50:44 2009 Subject: Can't use gpt labels re-importing pool In-Reply-To: <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> Message-ID: <20091126085034.GA51998@icarus.home.lan> On Thu, Nov 26, 2009 at 02:40:17AM -0600, Scot Hetzel wrote: > On 11/26/09, Arnaud Houdelette wrote: > > I just upgraded from 7.2 to 8.0. > > Under 7.2 the pool was like : > > NAME STATE READ WRITE CKSUM > > tank ONLINE 0 0 0 > > raidz1 ONLINE 0 0 0 > > ad6p1 ONLINE 0 0 0 > > ad10p1 ONLINE 0 0 0 > > ad8p1 ONLINE 0 0 0 > > ad4p1 ONLINE 0 0 0 > > > > I'd like to use gpt labels or gptids reimporting the pool. > > # ls /dev/gpt > > disk1 disk2 disk3 disk4 > > # ls /dev/gptid > > 0902db4e-d462-11de-96bd-001d923bc7a0 > > 9fb111f8-d426-11de-99bc-001d923bc7a0 > > 1be29091-d9dc-11de-9f4a-001d923bc7a0 > > ffb4e96a-d497-11de-96bd-001d923bc7a0 > > > > I did # zpool import -d /dev/gpt tank > > and I got > > tank ONLINE > > raidz1 ONLINE > > ada1p1 ONLINE > > ada3p1 ONLINE > > ada2p1 ONLINE > > gpt/disk4 ONLINE > > > > Now, how to force zpool import to only use gpt labels (or uuids) ? Or at > > least get back to coherent situation ( zpool export tank / zpool import > > gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid > > gives nothing ) ? > > > > Use 'zpool replace' to change the zfs pool to use the gpt names: > > zpool replace tank ada1p1 gpt/disk1 > zpool replace tank ada2p1 gpt/disk2 > zpool replace tank ada3p1 gpt/disk3 > > NOTE: make sure you use the correct gpt names for each partition, as > the above assumes that ada1p1 is labeled as disk1. I'm a bit curious about something, so maybe someone can help me understand: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mav at FreeBSD.org Thu Nov 26 09:09:23 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Nov 26 09:09:30 2009 Subject: how to disable APM using camcontrol cmd In-Reply-To: <1259162588.00187044.1259151005@10.7.7.3> References: <1259162588.00187044.1259151005@10.7.7.3> Message-ID: <4B0E45B1.90907@FreeBSD.org> Denis Shaposhnikov wrote: > I'm trying to replace sysutils/ataidle which doesn't work with new > acpi(4). May be somebody could tell me args for > > camcontrol cmd ada0 -a cmd XX XX XX XX XX XX XX XX > > to disable APM and acoustic management (AAM) for my HDD? To set APM level: camcontrol cmd ada0 -a "EF 05 00 00 00 00 00 00 00 00 xx 00" To disable it: camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 00 To set AAM level: camcontrol cmd ada0 -a "EF 42 00 00 00 00 00 00 00 00 xx 00" To disable it: camcontrol cmd ada0 -a "EF C2 00 00 00 00 00 00 00 00 00 00 You can check result with: camcontrol identify ada0 -- Alexander Motin From hselasky at c2i.net Thu Nov 26 09:18:58 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Nov 26 09:19:05 2009 Subject: 8.0-RC USB/FS problem In-Reply-To: References: <200911250937.08267.hselasky@c2i.net> Message-ID: <200911260920.32342.hselasky@c2i.net> On Thursday 26 November 2009 08:30:52 Guojun Jin wrote: > Most crash had the same back trace. This is also true when USB access > hangs, then unplug the drive. I think from the backtrace that this is not an USB issue. It is a file-system issue. --HPS From tevans.uk at googlemail.com Thu Nov 26 09:45:39 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Thu Nov 26 09:45:45 2009 Subject: Can't use gpt labels re-importing pool In-Reply-To: <20091126085034.GA51998@icarus.home.lan> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> Message-ID: <2e027be00911260145q4192728cuaea1d5e6da01a1e@mail.gmail.com> On Thu, Nov 26, 2009 at 8:50 AM, Jeremy Chadwick wrote: > I'm a bit curious about something, so maybe someone can help me > understand: > > Why are people bothering with GPT labels (or in some cases, glabels) > when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what > circumstance would the device name change dynamically in this situation? > > I've never witnessed this happening with AHCI, at least on Intel > systems, and I've hot-swapped hard disks many times over. > > My home server has 6 x ICH10 SATA ports using ahci(4), and 2 x SiL 3128 SATA ports using siis(4). When I first set it up, I created a raidz pool using MBR/BSD slices/partitions on the drives on the ahci controllers, (ie zpool create tank raidz ada[0-5]s1d). I then shutdown, connected a couple of drives to the siis controller, and booted up again. This caused the pool to fail to be imported, as the drives on siis came up as ada0 and ada1. I then wiped out the pool, and restarted the install, but this time using GPT partitioning and labelling each partition that I use. Now I can connect my drives on any interface, any order and it works correctly, always. I also get a nice label for each drive that I can scribble on the drive cage, and I can tell exactly what physical device is referred to by a label. The only cost to this was having to remember to label the drives - well worth it imo. Cheers Tom From dsh at wizard.volgograd.ru Thu Nov 26 10:11:29 2009 From: dsh at wizard.volgograd.ru (Denis Shaposhnikov) Date: Thu Nov 26 10:11:35 2009 Subject: how to disable APM using camcontrol cmd In-Reply-To: <4B0E45B1.90907@FreeBSD.org> References: <1259162588.00187044.1259151005@10.7.7.3> <4B0E45B1.90907@FreeBSD.org> Message-ID: <20091126125225.500f9dd7@wizard.volgograd.ru> Hello, On Thu, 26 Nov 2009 11:09:05 +0200 Alexander Motin wrote: > To set APM level: > camcontrol cmd ada0 -a "EF 05 00 00 00 00 00 00 00 00 xx 00" > To disable it: > camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 00 Yes, it works! Thank you very much! From swhetzel at gmail.com Thu Nov 26 10:29:18 2009 From: swhetzel at gmail.com (Scot Hetzel) Date: Thu Nov 26 10:29:25 2009 Subject: Can't use gpt labels re-importing pool In-Reply-To: <20091126085034.GA51998@icarus.home.lan> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> Message-ID: <790a9fff0911260229u40d9f499w28a7ce46e1f92467@mail.gmail.com> On 11/26/09, Jeremy Chadwick wrote: > I'm a bit curious about something, so maybe someone can help me > understand: > > Why are people bothering with GPT labels (or in some cases, glabels) > when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what > circumstance would the device name change dynamically in this situation? > There was a thread about this problem where the drives had changed their device names due to a change in the kernel drive (Current list from July): http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009377.html Through out this thread there were various suggests on how he could recover the system, and prevent the problem from occurring in the future. One of the suggestions was that use of zpool replace to change from device names to using glabel labels. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html > I've never witnessed this happening with AHCI, at least on Intel > systems, and I've hot-swapped hard disks many times over. > Using glabels, gpt labels, or gptid solves the problem of not needing to remember which device name the drive originally had. For instance, on a zfs zraid pool with 3 disks (ad1 ad2 ad3) you could disconnect the pool from one computer and connect it to another system and it wouldn't matter which order you reconnected the drives (1 2 3 or 3 1 2) as the pool would still be recognized when it is imported on the new system. Also if the new system already has drives ad1 and ad2, it wouldn't matter. Scot From arnaud.houdelette at tzim.net Thu Nov 26 11:09:27 2009 From: arnaud.houdelette at tzim.net (Arnaud Houdelette) Date: Thu Nov 26 11:09:34 2009 Subject: Can't use gpt labels re-importing pool In-Reply-To: <790a9fff0911260200kf07d6d2nf7cf9eb9d2c07bcf@mail.gmail.com> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <4B0E43B1.6050802@tzim.net> <790a9fff0911260200kf07d6d2nf7cf9eb9d2c07bcf@mail.gmail.com> Message-ID: <4B0E61E2.7070509@tzim.net> Scot Hetzel wrote: > On 11/26/09, Arnaud Houdelette wrote: > >> Scot Hetzel wrote: >> >> >>> On 11/26/09, Arnaud Houdelette wrote: >>> >>> >>> >>>> I just upgraded from 7.2 to 8.0. >>>> Under 7.2 the pool was like : >>>> NAME STATE READ WRITE CKSUM >>>> tank ONLINE 0 0 0 >>>> raidz1 ONLINE 0 0 0 >>>> ad6p1 ONLINE 0 0 0 >>>> ad10p1 ONLINE 0 0 0 >>>> ad8p1 ONLINE 0 0 0 >>>> ad4p1 ONLINE 0 0 0 >>>> >>>> I'd like to use gpt labels or gptids reimporting the pool. >>>> # ls /dev/gpt >>>> disk1 disk2 disk3 disk4 >>>> # ls /dev/gptid >>>> 0902db4e-d462-11de-96bd-001d923bc7a0 >>>> 9fb111f8-d426-11de-99bc-001d923bc7a0 >>>> 1be29091-d9dc-11de-9f4a-001d923bc7a0 >>>> ffb4e96a-d497-11de-96bd-001d923bc7a0 >>>> >>>> I did # zpool import -d /dev/gpt tank >>>> and I got >>>> tank ONLINE >>>> raidz1 ONLINE >>>> ada1p1 ONLINE >>>> ada3p1 ONLINE >>>> ada2p1 ONLINE >>>> gpt/disk4 ONLINE >>>> >>>> Now, how to force zpool import to only use gpt labels (or uuids) ? Or >>>> >> at >> >>>> least get back to coherent situation ( zpool export tank / zpool import >>>> gives the same now. and zpool import -d /dev, as zpool import -d >>>> >> /dev/gptid >> >>>> gives nothing ) ? >>>> >>>> >>>> >>>> >>> Use 'zpool replace' to change the zfs pool to use the gpt names: >>> >>> zpool replace tank ada1p1 gpt/disk1 >>> zpool replace tank ada2p1 gpt/disk2 >>> zpool replace tank ada3p1 gpt/disk3 >>> >>> NOTE: make sure you use the correct gpt names for each partition, as >>> the above assumes that ada1p1 is labeled as disk1. >>> >>> Scot >>> >>> >>> >> Mmmh, zpool replace will resilver the drive, won't it ? >> > > Yes, it will resilver the drive, but it shouldn't take as long as it > will recognize that it is the same drive. Just wait for the resilver > process to finish before changing the next drive. > > >> Moreover, I can't use replace as when adaXp1 is used, the corresponding >> /dev/gpt entry disapears. Unless you mean that I can use replace before >> import ? >> >> > > There was a discussion about this back in July: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html > > In that discussion, they had used glabel to label each drive, and then > use zpool replace on the active pool to change it to use the label. > > Just make sure that you use the gpt name that you assigned to ada1p1, > when replacing it. > > Scot > That does not work or there's something I'm doing wrong. # uname -a FreeBSD carenath.tzim.net 8.0-RELEASE FreeBSD 8.0-RELEASE #26: Wed Nov 25 23:43:22 CET 2009 tzim@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 As I said, the label is not present in /dev/gpt while used with adaXp1 ( here ada1p1 has label HD753LJ-1) : # ls /dev/gpt HD753LJ-4 zfs-boot # zpool replace tank ada1p1 gpt/HD753LJ-1 cannot open 'gpt/HD753LJ-1': no such GEOM provider If I offline the drive first, I get another error : # zpool offline tank ada1p1 # zpool replace tank ada1p1 gpt/HD753LJ-1 invalid vdev specification use '-f' to override the following errors: /dev/gpt/HD753LJ-1 is part of active pool 'tank' # zpool replace -f tank ada1p1 gpt/HD753LJ-1 invalid vdev specification the following errors must be manually repaired: /dev/gpt/HD753LJ-1 is part of active pool 'tank' I know there is the solution of cleaning the disk and resilvering, but if I could avoid this ? Arnaud From edhoprima at gmail.com Thu Nov 26 11:10:11 2009 From: edhoprima at gmail.com (Edho P Arief) Date: Thu Nov 26 11:10:18 2009 Subject: Can't use gpt labels re-importing pool In-Reply-To: <790a9fff0911260229u40d9f499w28a7ce46e1f92467@mail.gmail.com> References: <4B0E3ABA.3030606@tzim.net> <790a9fff0911260040i1456d7c0j4f8327d24d2966cf@mail.gmail.com> <20091126085034.GA51998@icarus.home.lan> <790a9fff0911260229u40d9f499w28a7ce46e1f92467@mail.gmail.com> Message-ID: