Re: Unnamed POSIX shared semaphores
On Mon, Jun 8, 2009 at 3:57 PM, Ivan Voras wrote: > On a completely unrelated subject I was reading about PHP APC cache > where they have the same need - cross-process locking with locks > embedded in data structures and they have adopted userland spinlock code > from PostgreSQL: > > http://www.scribd.com/doc/3288293/brian-shireapc-facebook > > (spin)locks are not the same as sempahores but maybe it will help the OP > or anyone else trying to implement this feature: > > http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4&view=markup > > http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3&view=markup Thanks, Ivan. I'll take a better look at this after our first release, which is due in a couple of weeks. Right now the team efforts aren't focused on portability, so it's a low priority issue, but something we'd definitely like to have in the future. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Bug between DRM, MSI, or somewhere, re7-stable amd64
I updated my recently acquired core-2 duo laptop to 7-stable amd64 (I had been running 7-stable i386 with few problems) and have acquired an apparent irq problem. Fortunately in debugging a linux shared-interrupt problem about a month ago I learned that the X server will happily accept mouse motion as if it was a display interrupt, so at least with some inconvenience I can read the screen... (the keyboard isn't so obliging) Ours does this too... /usr/src was picked up via svn on last Saturday morning EDT, ports via csup about the same time. I have no idea if this bug is in the intel driver, drm, or the core msi code... There are 2 peripherals that dmesg says uses msi - re0 (which doesn't get a kernel thread indicated in ps for either the stated irq (257) or re0) and drm0/vgapci0 (which indicates irq256 in systat and ps). As I said, this worked properly with earlier source (about a week) in i386 mode. I've used both G45 and re controllers in (f10) linux msi mode with no problems in both 32 and 64-bit. Fortunately this laptop now has enough disk to triple-boot so at least something works... I am using svn instead of csup because I am trying (haven't gotten time yet either :-) to port Sam's ath 92xx code to -stable and handling code porting is much easier that way. -- Pete ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on sparc64/sparc64
TB --- 2009-06-09 00:18:40 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 00:18:40 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-06-09 00:18:40 - cleaning the object tree TB --- 2009-06-09 00:19:03 - cvsupping the source tree TB --- 2009-06-09 00:19:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-06-09 00:19:15 - building world TB --- 2009-06-09 00:19:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 00:19:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 00:19:15 - TARGET=sparc64 TB --- 2009-06-09 00:19:15 - TARGET_ARCH=sparc64 TB --- 2009-06-09 00:19:15 - TZ=UTC TB --- 2009-06-09 00:19:15 - __MAKE_CONF=/dev/null TB --- 2009-06-09 00:19:15 - cd /src TB --- 2009-06-09 00:19:15 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 00:19:17 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 Jun 9 01:23:22 UTC 2009 TB --- 2009-06-09 01:23:22 - generating LINT kernel config TB --- 2009-06-09 01:23:22 - cd /src/sys/sparc64/conf TB --- 2009-06-09 01:23:22 - /usr/bin/make -B LINT TB --- 2009-06-09 01:23:22 - building LINT kernel TB --- 2009-06-09 01:23:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 01:23:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 01:23:22 - TARGET=sparc64 TB --- 2009-06-09 01:23:22 - TARGET_ARCH=sparc64 TB --- 2009-06-09 01:23:22 - TZ=UTC TB --- 2009-06-09 01:23:22 - __MAKE_CONF=/dev/null TB --- 2009-06-09 01:23:22 - cd /src TB --- 2009-06-09 01:23:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 01:23:22 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/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 01:27:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 01:27:18 - ERROR: failed to build lint kernel TB --- 2009-06-09 01:27:18 - 3339.84 user 359.49 system 4118.37 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on powerpc/powerpc
TB --- 2009-06-08 23:55:30 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 23:55:30 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-06-08 23:55:30 - cleaning the object tree TB --- 2009-06-08 23:55:50 - cvsupping the source tree TB --- 2009-06-08 23:55:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-06-08 23:56:02 - building world TB --- 2009-06-08 23:56:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 23:56:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 23:56:02 - TARGET=powerpc TB --- 2009-06-08 23:56:02 - TARGET_ARCH=powerpc TB --- 2009-06-08 23:56:02 - TZ=UTC TB --- 2009-06-08 23:56:02 - __MAKE_CONF=/dev/null TB --- 2009-06-08 23:56:02 - cd /src TB --- 2009-06-08 23:56:02 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 23:56:03 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 Jun 9 01:04:55 UTC 2009 TB --- 2009-06-09 01:04:55 - generating LINT kernel config TB --- 2009-06-09 01:04:55 - cd /src/sys/powerpc/conf TB --- 2009-06-09 01:04:55 - /usr/bin/make -B LINT TB --- 2009-06-09 01:04:55 - building LINT kernel TB --- 2009-06-09 01:04:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 01:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 01:04:55 - TARGET=powerpc TB --- 2009-06-09 01:04:55 - TARGET_ARCH=powerpc TB --- 2009-06-09 01:04:55 - TZ=UTC TB --- 2009-06-09 01:04:55 - __MAKE_CONF=/dev/null TB --- 2009-06-09 01:04:55 - cd /src TB --- 2009-06-09 01:04:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 01:04:55 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/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 01:08:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 01:08:45 - ERROR: failed to build lint kernel TB --- 2009-06-09 01:08:45 - 3564.34 user 363.25 system 4394.38 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on ia64/ia64
TB --- 2009-06-08 22:42:38 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 22:42:38 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-06-08 22:42:39 - cleaning the object tree TB --- 2009-06-08 22:43:09 - cvsupping the source tree TB --- 2009-06-08 22:43:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-06-08 22:43:20 - building world TB --- 2009-06-08 22:43:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:43:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:43:20 - TARGET=ia64 TB --- 2009-06-08 22:43:20 - TARGET_ARCH=ia64 TB --- 2009-06-08 22:43:20 - TZ=UTC TB --- 2009-06-08 22:43:20 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:43:20 - cd /src TB --- 2009-06-08 22:43:20 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 22:43:22 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 Jun 9 00:12:39 UTC 2009 TB --- 2009-06-09 00:12:39 - generating LINT kernel config TB --- 2009-06-09 00:12:39 - cd /src/sys/ia64/conf TB --- 2009-06-09 00:12:39 - /usr/bin/make -B LINT TB --- 2009-06-09 00:12:39 - building LINT kernel TB --- 2009-06-09 00:12:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 00:12:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 00:12:39 - TARGET=ia64 TB --- 2009-06-09 00:12:39 - TARGET_ARCH=ia64 TB --- 2009-06-09 00:12:39 - TZ=UTC TB --- 2009-06-09 00:12:39 - __MAKE_CONF=/dev/null TB --- 2009-06-09 00:12:39 - cd /src TB --- 2009-06-09 00:12:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 00:12:39 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/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 00:18:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 00:18:39 - ERROR: failed to build lint kernel TB --- 2009-06-09 00:18:39 - 4806.28 user 390.27 system 5760.57 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on i386/pc98
TB --- 2009-06-08 22:42:21 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 22:42:21 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-06-08 22:42:21 - cleaning the object tree TB --- 2009-06-08 22:42:52 - cvsupping the source tree TB --- 2009-06-08 22:42:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-06-08 22:43:04 - building world TB --- 2009-06-08 22:43:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:43:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:43:04 - TARGET=pc98 TB --- 2009-06-08 22:43:04 - TARGET_ARCH=i386 TB --- 2009-06-08 22:43:04 - TZ=UTC TB --- 2009-06-08 22:43:04 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:43:04 - cd /src TB --- 2009-06-08 22:43:04 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 22:43:06 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 Mon Jun 8 23:50:39 UTC 2009 TB --- 2009-06-08 23:50:39 - generating LINT kernel config TB --- 2009-06-08 23:50:39 - cd /src/sys/pc98/conf TB --- 2009-06-08 23:50:39 - /usr/bin/make -B LINT TB --- 2009-06-08 23:50:39 - building LINT kernel TB --- 2009-06-08 23:50:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 23:50:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 23:50:39 - TARGET=pc98 TB --- 2009-06-08 23:50:39 - TARGET_ARCH=i386 TB --- 2009-06-08 23:50:39 - TZ=UTC TB --- 2009-06-08 23:50:39 - __MAKE_CONF=/dev/null TB --- 2009-06-08 23:50:39 - cd /src TB --- 2009-06-08 23:50:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 23:50:39 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/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 23:55:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 23:55:30 - ERROR: failed to build lint kernel TB --- 2009-06-08 23:55:30 - 3445.74 user 392.66 system 4388.88 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problem still remains with 7.2-STABLE locking up
I got a lockup at 3 a.m. JST, but because I'm not ready for dcons I cannot show you guys the whole ddb session. I put a 'bt' output of kgdb. http://www.heimat.gr.jp/localhost/kgdbbtvmcore.0 Kernel config: include GENERIC ident HEIMAT options MSGBUF_SIZE=81920 makeoptions DEBUG=-g options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options BREAK_TO_DEBUGGER options QUOTA options DEVICE_POLLING options HZ=1000 options SW_WATCHDOG options DEBUG_VFS_LOCKS options INVARIANTS options INVARIANT_SUPPORT options WITNESS Thanks. P.S. "allthreads" was not a usable command in my RELENG_7's ddb. > In <3bbf2fe10906060749xbbc2f2fy4c09f67711a...@mail.gmail.com> > Attilio Rao wrote: > Anyways, the only one way we have to debug this is getting some help > by the user. > 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug > spinlocks too) and LOCK_PROFILING (in order to create higher > contention and kill some barriers) > 2) Once you get the deadlock break in the DDB debugger > 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads > Note that this is a lot of printout so you won't be able of collecting > all these informations if not with a serial connection. > 4) Dump the content so that we can further look at locks structure > states once we identify something useful (ideally, keeping the machine > up in DDB for that would be very useful, but often not viable) > Let me know. > Attilio -- NAKAJI Hiroyuki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on i386/i386
TB --- 2009-06-08 21:28:33 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 21:28:33 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-08 21:28:33 - cleaning the object tree TB --- 2009-06-08 21:28:56 - cvsupping the source tree TB --- 2009-06-08 21:28:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-08 21:29:10 - building world TB --- 2009-06-08 21:29:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 21:29:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 21:29:10 - TARGET=i386 TB --- 2009-06-08 21:29:10 - TARGET_ARCH=i386 TB --- 2009-06-08 21:29:10 - TZ=UTC TB --- 2009-06-08 21:29:10 - __MAKE_CONF=/dev/null TB --- 2009-06-08 21:29:10 - cd /src TB --- 2009-06-08 21:29:10 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 21:29:11 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 Mon Jun 8 22:36:06 UTC 2009 TB --- 2009-06-08 22:36:06 - generating LINT kernel config TB --- 2009-06-08 22:36:06 - cd /src/sys/i386/conf TB --- 2009-06-08 22:36:06 - /usr/bin/make -B LINT TB --- 2009-06-08 22:36:06 - building LINT kernel TB --- 2009-06-08 22:36:06 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:36:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:36:06 - TARGET=i386 TB --- 2009-06-08 22:36:06 - TARGET_ARCH=i386 TB --- 2009-06-08 22:36:06 - TZ=UTC TB --- 2009-06-08 22:36:06 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:36:06 - cd /src TB --- 2009-06-08 22:36:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 22:36:06 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/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 22:42:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 22:42:21 - ERROR: failed to build lint kernel TB --- 2009-06-08 22:42:21 - 3545.02 user 387.44 system 4427.29 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
flooded with "ath0: stuck beacon; resetting (bmiss count 4)" after upgrade to 7.2-stable
After upgrading from FreeBSD 7.1-RELEASE to FreeBSD 7.2-STABLE I Get a gazillion of these : kernel: ath0: stuck beacon; resetting (bmiss count 4) in /var/log/messages Mostly when all workstations are turned off. The messagestorm slows down after the first workstation has connected, but there are still a LOT of messages The Hardware is exactly the same as before the upgrade. No change whatsoever. I am uing the atheros card as a host AP and I have tried different settings with ifconfig like -bgscan to no avail. So please : how to stop these emssages ? v8 # ifconfig ath0 ath0: flags=8943 metric 0 mtu 2290 ether 00:18:4d:ec:7d:07 inet 192.168.1.103 netmask 0xff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid XX channel 1 (2412 Mhz 11g) bssid 00:18:4d:ec:7d:07 authmode WPA1+WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 1000 protmode CTS burst hidessid dtimperiod 1 Current dmesg from 7.2 stable : = 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 7.2-STABLE #2: Sun Jun 7 17:14:11 CEST 2009 t...@v8.y.dk:/usr/obj/usr/src/sys/V8 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1600+ (1401.72-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc0480800 real memory = 805240832 (767 MB) avail memory = 773959680 (738 MB) kbd1 at kbdmux0 acpi0: <761686 AWRDACPI> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 2fef (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc400-0xc40f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xc800-0xc81f irq 5 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc00-0xcc1f irq 5 at device 7.3 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) vgapci0: mem 0xf000-0xf0003fff,0xf100-0xf17f irq 5 at device 11.0 on pci0 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xd000-0xd03f irq 12 at device 15.0 on pci0 miibus0: on xl0 nsphy0: PHY 24 on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:57:5a:bf xl0: [ITHREAD] ath0: mem 0xf300-0xf300 irq 10 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:18:4d:ec:7d:07 ath0: mac 7.9 phy 4.5 radio 5.6 atapci1: port 0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07,0xe000-0xe003,0xe400-0xe4ff irq 11 at device 19.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [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_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc-0xc7fff pnpid ORM on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 1401715949 Hz quality 800 Timecounters tick every 1.000 msec ad0: 152627MB at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA66 ad4: 152627MB at ata2-master UDMA100 ad6: 152627MB at ata3-master UDMA100 GEOM_MIRROR: Device mirror/gm0s1 launched (1/1). GEOM_MIRROR: Device gm0s1: provider ad
Re: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327
On Mon, Jun 08, 2009 at 08:25:50PM +0300, Mikolaj Golub wrote:
> After recent upgrade (on June 3) of my 7-stable host (WITNESS is enabled, the
> previous build was Apr 26), I have been experienced panics when starting some
> our home made application:
>
> Architecture: i386
> Architecture Version: 2
> Dump Length: 73797632B (70 MB)
> Blocksize: 512
> Dumptime: Mon Jun 8 15:29:14 2009
> Hostname: zhuzha.ua1
> Magic: FreeBSD Kernel Dump
> Version String: FreeBSD 7.2-STABLE #18: Wed Jun 3 14:28:49 EEST 2009
> r...@zhuzha.ua1:/usr/obj/usr/src/sys/DEBUG
> Panic String: Assertion lock == sq->sq_lock failed at
> /usr/src/sys/kern/subr_sleepqueue.c:327
> Dump Parity: 1277108796
> Bounds: 18
>
> Narrowing down the problem I have written a simple test program (in attaches)
> that models in simplified way the behaviour or our application and reproduces
> the crash. There are two threads. One of the threads is doing vfork/exec to
> start child process while the other is monitoring the status of the child
> calling wait4().
>
> At the moment of the crash the parent vfork thread is sleeping on
> wchan=0xc4d17ae0 (td->td_proc) with lock=0xc4d178b8 waiting for the child to
> exec. The parent wait4 thread with lock=0xc4d17b70 and the same wchan calls
> sleepq_lookup(wchan) to check if the wait channel already have a sleep queue
> associated with it, finds the queue of the vfork thread, tries to insert the
> current thread into this sleep queue and fails on assertion lock==sq->sq_lock.
>
> wait4 treead:
>
> (kgdb) thr 128
> [Switching to thread 128 (Thread 100164)]#0 doadump () at pcpu.h:196
> 196 in pcpu.h
> (kgdb) bt
> #0 doadump () at pcpu.h:196
> #1 0xc0496509 in db_fncall (dummy1=-1061924641, dummy2=0, dummy3=-1,
> dummy4=0xe69a089c "")
> at /usr/src/sys/ddb/db_command.c:516
> #2 0xc0496abf in db_command (last_cmdp=0xc0c9ab54, cmd_table=0x0, dopager=0)
> at /usr/src/sys/ddb/db_command.c:413
> #3 0xc0496b34 in db_command_script (command=0xc0c9baa4 "call doadump")
> at /usr/src/sys/ddb/db_command.c:484
> #4 0xc049a3a0 in db_script_exec (scriptname=0xe69a09a8 "kdb.enter.panic",
> warnifnotfound=Variable "warnifnotfound" is not available.
> )
> at /usr/src/sys/ddb/db_script.c:302
> #5 0xc049a47d in db_script_kdbenter (eventname=0xc0b8fa85 "panic") at
> /usr/src/sys/ddb/db_script.c:324
> #6 0xc0498388 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:227
> #7 0xc0810d36 in kdb_trap (type=3, code=0, tf=0xe69a0ae0) at
> /usr/src/sys/kern/subr_kdb.c:524
> #8 0xc0add6ab in trap (frame=0xe69a0ae0) at /usr/src/sys/i386/i386/trap.c:688
> #9 0xc0ac159b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #10 0xc0810eba in kdb_enter_why (why=0xc0b8fa85 "panic", msg=0xc0b8fa85
> "panic") at cpufunc.h:60
> #11 0xc07e4216 in panic (fmt=0xc0b5ecd3 "Assertion %s failed at %s:%d")
> at /usr/src/sys/kern/kern_shutdown.c:557
> #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70,
> wmesg=0xc0b959c1 "wait", flags=256,
> queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327
> #13 0xc07ec94b in _sleep (ident=0xc4d17ae0, lock=Variable "lock" is not
> available.
> ) at /usr/src/sys/kern/kern_synch.c:203
> #14 0xc07bd8e6 in kern_wait (td=0xc41e8480, pid=-1, status=0xe69a0c2c,
> options=Variable "options" is not available.
> )
> at /usr/src/sys/kern/kern_exit.c:902
> #15 0xc07bd95b in wait4 (td=0xc41e8480, uap=0xe69a0cfc) at
> /usr/src/sys/kern/kern_exit.c:688
> #16 0xc0adce23 in syscall (frame=0xe69a0d38) at
> /usr/src/sys/i386/i386/trap.c:1090
> #17 0xc0ac1600 in Xint0x80_syscall () at
> /usr/src/sys/i386/i386/exception.s:255
> #18 0x0033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) fr 12
> #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70,
> wmesg=0xc0b959c1 "wait", flags=256,
> queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327
> 327 MPASS(lock == sq->sq_lock);
> (kgdb) p lock
> $1 = (struct lock_object *) 0xc4d17b70
> (kgdb) p sq->sq_lock
> $2 = (struct lock_object *) 0xc4d178b8
> (kgdb) p *lock
> $3 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process
> lock", lo_flags = 21168128,
> lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness =
> 0xc0ce4840}}
> (kgdb) p *sq->sq_lock
> $4 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process
> lock", lo_flags = 21168128,
> lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness =
> 0xc0ce4840}}
>
> vfork thread of the parent process:
>
> (kgdb) thr 127
> [Switching to thread 127 (Thread 100162)]#0 sched_switch (td=0xc41e86c0,
> newtd=Variable "newtd" is not available.
> )
> at /usr/src/sys/kern/sched_ule.c:1944
> 1944cpuid = PCPU_GET(cpuid);
> (kgdb) bt
> #0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available.
> ) at /usr/src/sys/kern/sched_ule.c:1944
> #1 0xc07ec4c3 in mi_switch (flags=Varia
Re: /boot/loader and RELENG_7 (WAS: gptzfsboot and RELENG_7)
Dan Naumov wrote: Ah, so there is still a (small) piece of 8-CURRENT needed to have a working 7-STABLE zfs boot configuration? I am getting really confused now, if I add LOADER_ZFS_SUPPORT=yes to my /etc/make.conf, the RELENG_7 system will be built with zfs boot support, but I still need the actual /boot/loader from 8-CURRENT? Is that getting MFC'ed into into RELENG_7 anytime soon? Where are all make.conf options documented by the way? Neither /usr/share/examples/etc/make.conf nor "man make.conf" make any reference to the LOADER_ZFS_SUPPORT option. - Dan Naumov ZFS booting without partitions See the last emails in the thread "ZFS booting without partitions", it has a patch which makes the -stable loader work (some changes that didn't get merged to -stable). I think only the change from 8 to 64 is all thats needed but I applied the whole patch when I tested it. Also, yes LOADER_ZFS_SUPPORT causes gptzfsboot to be compiled as well as add ZFS support to loader (and other stuff). It may not have been documented (I didn't check). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327
After recent upgrade (on June 3) of my 7-stable host (WITNESS is enabled, the
previous build was Apr 26), I have been experienced panics when starting some
our home made application:
Architecture: i386
Architecture Version: 2
Dump Length: 73797632B (70 MB)
Blocksize: 512
Dumptime: Mon Jun 8 15:29:14 2009
Hostname: zhuzha.ua1
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 7.2-STABLE #18: Wed Jun 3 14:28:49 EEST 2009
r...@zhuzha.ua1:/usr/obj/usr/src/sys/DEBUG
Panic String: Assertion lock == sq->sq_lock failed at
/usr/src/sys/kern/subr_sleepqueue.c:327
Dump Parity: 1277108796
Bounds: 18
Narrowing down the problem I have written a simple test program (in attaches)
that models in simplified way the behaviour or our application and reproduces
the crash. There are two threads. One of the threads is doing vfork/exec to
start child process while the other is monitoring the status of the child
calling wait4().
At the moment of the crash the parent vfork thread is sleeping on
wchan=0xc4d17ae0 (td->td_proc) with lock=0xc4d178b8 waiting for the child to
exec. The parent wait4 thread with lock=0xc4d17b70 and the same wchan calls
sleepq_lookup(wchan) to check if the wait channel already have a sleep queue
associated with it, finds the queue of the vfork thread, tries to insert the
current thread into this sleep queue and fails on assertion lock==sq->sq_lock.
wait4 treead:
(kgdb) thr 128
[Switching to thread 128 (Thread 100164)]#0 doadump () at pcpu.h:196
196 in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc0496509 in db_fncall (dummy1=-1061924641, dummy2=0, dummy3=-1,
dummy4=0xe69a089c "")
at /usr/src/sys/ddb/db_command.c:516
#2 0xc0496abf in db_command (last_cmdp=0xc0c9ab54, cmd_table=0x0, dopager=0)
at /usr/src/sys/ddb/db_command.c:413
#3 0xc0496b34 in db_command_script (command=0xc0c9baa4 "call doadump")
at /usr/src/sys/ddb/db_command.c:484
#4 0xc049a3a0 in db_script_exec (scriptname=0xe69a09a8 "kdb.enter.panic",
warnifnotfound=Variable "warnifnotfound" is not available.
)
at /usr/src/sys/ddb/db_script.c:302
#5 0xc049a47d in db_script_kdbenter (eventname=0xc0b8fa85 "panic") at
/usr/src/sys/ddb/db_script.c:324
#6 0xc0498388 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:227
#7 0xc0810d36 in kdb_trap (type=3, code=0, tf=0xe69a0ae0) at
/usr/src/sys/kern/subr_kdb.c:524
#8 0xc0add6ab in trap (frame=0xe69a0ae0) at /usr/src/sys/i386/i386/trap.c:688
#9 0xc0ac159b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#10 0xc0810eba in kdb_enter_why (why=0xc0b8fa85 "panic", msg=0xc0b8fa85
"panic") at cpufunc.h:60
#11 0xc07e4216 in panic (fmt=0xc0b5ecd3 "Assertion %s failed at %s:%d")
at /usr/src/sys/kern/kern_shutdown.c:557
#12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70,
wmesg=0xc0b959c1 "wait", flags=256,
queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327
#13 0xc07ec94b in _sleep (ident=0xc4d17ae0, lock=Variable "lock" is not
available.
) at /usr/src/sys/kern/kern_synch.c:203
#14 0xc07bd8e6 in kern_wait (td=0xc41e8480, pid=-1, status=0xe69a0c2c,
options=Variable "options" is not available.
)
at /usr/src/sys/kern/kern_exit.c:902
#15 0xc07bd95b in wait4 (td=0xc41e8480, uap=0xe69a0cfc) at
/usr/src/sys/kern/kern_exit.c:688
#16 0xc0adce23 in syscall (frame=0xe69a0d38) at
/usr/src/sys/i386/i386/trap.c:1090
#17 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#18 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 12
#12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70,
wmesg=0xc0b959c1 "wait", flags=256,
queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327
327 MPASS(lock == sq->sq_lock);
(kgdb) p lock
$1 = (struct lock_object *) 0xc4d17b70
(kgdb) p sq->sq_lock
$2 = (struct lock_object *) 0xc4d178b8
(kgdb) p *lock
$3 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock",
lo_flags = 21168128,
lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness =
0xc0ce4840}}
(kgdb) p *sq->sq_lock
$4 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock",
lo_flags = 21168128,
lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness =
0xc0ce4840}}
vfork thread of the parent process:
(kgdb) thr 127
[Switching to thread 127 (Thread 100162)]#0 sched_switch (td=0xc41e86c0,
newtd=Variable "newtd" is not available.
)
at /usr/src/sys/kern/sched_ule.c:1944
1944cpuid = PCPU_GET(cpuid);
(kgdb) bt
#0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
#1 0xc07ec4c3 in mi_switch (flags=Variable "flags" is not available.
) at /usr/src/sys/kern/kern_synch.c:444
#2 0xc0818bd2 in sleepq_switch (wchan=0xc4d17ae0) at
/usr/src/sys/kern/subr_sleepqueue.c:497
#3 0xc0819800 in sleepq_wait (wchan=0xc4d17ae0) at
/usr/src/sys/kern/subr_sleepqueue.c:580
#4 0xc07eca69 in _sleep (
Re: /boot/loader and RELENG_7 (WAS: gptzfsboot and RELENG_7)
Ah, so there is still a (small) piece of 8-CURRENT needed to have a working 7-STABLE zfs boot configuration? I am getting really confused now, if I add LOADER_ZFS_SUPPORT=yes to my /etc/make.conf, the RELENG_7 system will be built with zfs boot support, but I still need the actual /boot/loader from 8-CURRENT? Is that getting MFC'ed into into RELENG_7 anytime soon? Where are all make.conf options documented by the way? Neither /usr/share/examples/etc/make.conf nor "man make.conf" make any reference to the LOADER_ZFS_SUPPORT option. - Dan Naumov On Mon, Jun 8, 2009 at 7:49 PM, Alberto Villa wrote: > On Monday 08 June 2009 17:44:40 Dan Naumov wrote: >> Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 >> indicated that even after that MFC, you still needed gptzfsboot from >> 8-CURRENT to be able to boot from a full ZFS system. Is this not the >> case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot >> in my /boot, only gptboot. I didn't make any changes to the stock >> Makefiles and used GENERIC kernel config. Do I need to adjust some >> options for gptzfsboot to get built? > > no, it's /boot/loader from 8-current which is needed (the one shared on this > list works perfectly for me) > to build your system with zfs boot support just add LOADER_ZFS_SUPPORT=yes > to /etc/make.conf > -- > Alberto Villa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gptzfsboot and RELENG_7
On Monday 08 June 2009 17:44:40 Dan Naumov wrote: > Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 > indicated that even after that MFC, you still needed gptzfsboot from > 8-CURRENT to be able to boot from a full ZFS system. Is this not the > case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot > in my /boot, only gptboot. I didn't make any changes to the stock > Makefiles and used GENERIC kernel config. Do I need to adjust some > options for gptzfsboot to get built? no, it's /boot/loader from 8-current which is needed (the one shared on this list works perfectly for me) to build your system with zfs boot support just add LOADER_ZFS_SUPPORT=yes to /etc/make.conf -- Alberto Villa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gptzfsboot and RELENG_7
Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 indicated that even after that MFC, you still needed gptzfsboot from 8-CURRENT to be able to boot from a full ZFS system. Is this not the case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot in my /boot, only gptboot. I didn't make any changes to the stock Makefiles and used GENERIC kernel config. Do I need to adjust some options for gptzfsboot to get built? - Dan Naumov >> > > 5/25/09 - last month > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic resource_list_alloc 7.2 stable
On Saturday 06 June 2009 10:14:31 am Robert wrote:
> Greetings
>
> This problem seems the same as this one from May of this year
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html
>
> This happens on an older HP laptop. It was running on 7.1 prerelease
> fine and then I updated to 7.2 Stable yesterday.
>
> FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri Jun 5
> 11:47:29 PDT 2009
> r...@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386
>
> The bits from pciconf
>
> atap...@pci0:0:7:1: class=0x010180 card=0x chip=0x71118086
> rev=0x01 hdr=0x00 vendor = 'Intel Corporation'
> device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller'
> class = mass storage
> subclass = ATA
>
> The date of ata-chipset.c
>
> -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c
>
> The chipset is found in the above file
>
> ata_intel_ident(device_t dev)
> {
> struct ata_pci_controller *ctlr = device_get_softc(dev);
> static struct ata_chip_id ids[] =
> {{ ATA_I82371FB, 0,0, 2, ATA_WDMA2, "PIIX" },
> { ATA_I82371SB, 0,0, 2, ATA_WDMA2, "PIIX3" },
> { ATA_I82371AB, 0,0, 2, ATA_UDMA2, "PIIX4" },
> ^^^
> { ATA_I82443MX, 0,0, 2, ATA_UDMA2, "PIIX4" },
>
> I can include the dump if needed but I am not at this time to shorten
> the email. But here is the panic.
>
> Dump header from device /dev/ad0s1b
> Architecture: i386
> Architecture Version: 2
> Dump Length: 68939776B (65 MB)
> Blocksize: 512
> Dumptime: Sat Jun 6 05:40:52 2009
> Hostname: hp.shasta204.local
> Magic: FreeBSD Kernel Dump
> Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT 2009
> r...@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA
> Panic String: resource_list_alloc: resource entry is busy
> Dump Parity: 3285399556
> Bounds: 1
> Dump Status: good
>
>
> Any help would be greatly appreciated.
The last screen of the dmesg output would be helpful.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems with PATA disk
On Mon, 8 Jun 2009 10:18:37 -0400 Adam K Kirchhoff wrote: > > My old workstation finally died and replaced by a Dell Vostro 420. > Since the hard drives on the old machine were fine, I decided to throw > them into the new machine. The new machine only had SATA onboard, so I added > a Promise controller to the mix: > > atap...@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a > rev=0x020 > vendor = 'Promise Technology Inc' > > device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' > > class = mass storage > > It has two SATA connectors and a single PATA connector. I had two PATA > drives, so that worked out fine, and I hooked them up. The master was > the master in the old machine and the slave was the slave in the old > machine. No need to change anything around. > > At first everything was fine. I booted up (using GENERIC, as I nearly > always do) and ran for a while. The machine locked up and I decided to > bring the machine up in single user mode and run an fsck. It ran just > fine on / /tmp /var and /usr (all on the master drive, ad14). I then > ran the fsck on ad15s1a (/home). Unfortunately, I almost immediately > started receiving 'WARNING - SETFEATURES SET TRANSFER MODE taskqueue > timeout' messages (along with various other SETFEATURES messages). > They were proceeded by both ad14 and ad15 (though, as I said, ad14 > fsck'ed fine). > > This continued for 30 minutes before I gave up and rebooted. When the > machine came back up, ad15 had no partition table or disklabel. And > fdisk refused to create a partition. > > Assuming that the drive had gone bad, I swapped it out with another > drive. Created a new partition, and labelled it. Restored /home from > backups. It ran for about a week, but locked up on me today (as > before, when doing something 3D, so I do not believe the backups are > related to disk activity), and I decided to manually run a fsck on the > system. Unfortunately, I received the same SETFEATURES messages as > before when fsck'ing /home. Instead of letting it run for 30 minutes, I > stopped after the messages flashed by the screen. I rebooted. The > partition table is hosed and there is no disklabel. > > When I go to create a new partition (per the directions > in /usr/share/doc/handbook/disks-adding.html, which is what I used > without any problems when I threw the new drive into the system), this > is what I happens: > > [ r...@memory - ~ ]: dd if=/dev/zero of=/dev/ad15 bs=1k count=1 > 1+0 records in > 1+0 records out > 1024 bytes transferred in 0.000118 secs (8676702 bytes/sec) > [ r...@memory - ~ ]: fdisk -BI ad15 > *** Working on device /dev/ad15 *** > fdisk: invalid fdisk partition table found > fdisk: Geom not found: "ad15" > [ r...@memory - ~ ]: bsdlabel -B -w ad15s1 auto > bsdlabel: /dev/ad15s1: No such file or directory > > And, indeed, there is still only /dev/ad15. > > So I have a few questions... > > Why do I keep losing my data? > How can I partition and label either one of these drives? > > Some system information: > > [ r...@memory - ~ ]: uname -a > FreeBSD memory.visualtech.com 7.2-STABLE FreeBSD 7.2-STABLE #5: Fri May 8 > 14:02:01 EDT 2009 r...@memory.visualtech.com:/usr/obj/usr/src/sys/GENERIC > i386 > [ r...@memory - ~ ]: pciconf -vl > hos...@pci0:0:0:0:class=0x06 card=0x02821028 chip=0x2e208086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > pc...@pci0:0:1:0: class=0x060400 card=0x02821028 chip=0x2e218086 rev=0x03 > hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > uh...@pci0:0:26:0:class=0x0c0300 card=0x02821028 chip=0x3a378086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uh...@pci0:0:26:1:class=0x0c0300 card=0x02821028 chip=0x3a388086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uh...@pci0:0:26:2:class=0x0c0300 card=0x02821028 chip=0x3a398086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > eh...@pci0:0:26:7:class=0x0c0320 card=0x02821028 chip=0x3a3c8086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > pc...@pci0:0:28:0:class=0x060400 card=0x02821028 chip=0x3a408086 rev=0x00 > hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pc...@pci0:0:28:1:class=0x060400 card=0x02821028 chip=0x3a428086 rev=0x00 > hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pc...@pci0:0:28:2:class=0x060400 card=0x02821028 chip=0x3a448086 rev=0x00 > hdr=0x01 >
gptzfsboot and RELENG_7
Hello list Any ideas if gptzfsboot is going to be MFC'ed into RELENG_7 anytime soon? I am going to be building a NAS soon and I would like to have a "full ZFS" system without having to resort to running 8-CURRENT :) Sincerely, - Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Problems with PATA disk
My old workstation finally died and replaced by a Dell Vostro 420. Since the hard drives on the old machine were fine, I decided to throw them into the new machine. The new machine only had SATA onboard, so I added a Promise controller to the mix: atap...@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 vendor = 'Promise Technology Inc' device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' class = mass storage It has two SATA connectors and a single PATA connector. I had two PATA drives, so that worked out fine, and I hooked them up. The master was the master in the old machine and the slave was the slave in the old machine. No need to change anything around. At first everything was fine. I booted up (using GENERIC, as I nearly always do) and ran for a while. The machine locked up and I decided to bring the machine up in single user mode and run an fsck. It ran just fine on / /tmp /var and /usr (all on the master drive, ad14). I then ran the fsck on ad15s1a (/home). Unfortunately, I almost immediately started receiving 'WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout' messages (along with various other SETFEATURES messages). They were proceeded by both ad14 and ad15 (though, as I said, ad14 fsck'ed fine). This continued for 30 minutes before I gave up and rebooted. When the machine came back up, ad15 had no partition table or disklabel. And fdisk refused to create a partition. Assuming that the drive had gone bad, I swapped it out with another drive. Created a new partition, and labelled it. Restored /home from backups. It ran for about a week, but locked up on me today (as before, when doing something 3D, so I do not believe the backups are related to disk activity), and I decided to manually run a fsck on the system. Unfortunately, I received the same SETFEATURES messages as before when fsck'ing /home. Instead of letting it run for 30 minutes, I stopped after the messages flashed by the screen. I rebooted. The partition table is hosed and there is no disklabel. When I go to create a new partition (per the directions in /usr/share/doc/handbook/disks-adding.html, which is what I used without any problems when I threw the new drive into the system), this is what I happens: [ r...@memory - ~ ]: dd if=/dev/zero of=/dev/ad15 bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000118 secs (8676702 bytes/sec) [ r...@memory - ~ ]: fdisk -BI ad15 *** Working on device /dev/ad15 *** fdisk: invalid fdisk partition table found fdisk: Geom not found: "ad15" [ r...@memory - ~ ]: bsdlabel -B -w ad15s1 auto bsdlabel: /dev/ad15s1: No such file or directory And, indeed, there is still only /dev/ad15. So I have a few questions... Why do I keep losing my data? How can I partition and label either one of these drives? Some system information: [ r...@memory - ~ ]: uname -a FreeBSD memory.visualtech.com 7.2-STABLE FreeBSD 7.2-STABLE #5: Fri May 8 14:02:01 EDT 2009 r...@memory.visualtech.com:/usr/obj/usr/src/sys/GENERIC i386 [ r...@memory - ~ ]: pciconf -vl hos...@pci0:0:0:0: class=0x06 card=0x02821028 chip=0x2e208086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pc...@pci0:0:1:0: class=0x060400 card=0x02821028 chip=0x2e218086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI uh...@pci0:0:26:0: class=0x0c0300 card=0x02821028 chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uh...@pci0:0:26:1: class=0x0c0300 card=0x02821028 chip=0x3a388086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uh...@pci0:0:26:2: class=0x0c0300 card=0x02821028 chip=0x3a398086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB eh...@pci0:0:26:7: class=0x0c0320 card=0x02821028 chip=0x3a3c8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pc...@pci0:0:28:0: class=0x060400 card=0x02821028 chip=0x3a408086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pc...@pci0:0:28:1: class=0x060400 card=0x02821028 chip=0x3a428086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pc...@pci0:0:28:2: class=0x060400 card=0x02821028 chip=0x3a448086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI uh...@pci0:0:29:0: class=0x0c0300 card=0x02821028 chip=0x3a348086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uh...@pci0:0:29:
Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf
Kip Macy wrote: The second bug is the use of LOADER_ZFS_SUPPORT without any consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) I'll try get it fixed by Wednesday. Kip, I noticed a fix went in with revision 193494 but was then backed out straight away with no reason. Will this be fixed soon? It is still not possible to build RELENG_7 sources WITHOUT_CDDL. Regards, Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Announcement: PmcTools merged to RELENG_7
Hello, The PmcTools is merged to RELENG_7. You can now enjoy the same level of features / hw supported as in head: - Callchain in capture - Core 2 support - Core i7 support - pmcannotate: source code annotation using pmc capture - bug fixes ... Tell me if you find any problems with it. Fabien ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unnamed POSIX shared semaphores
John Baldwin wrote: > On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote: >> Jilles Tjoelker wrote: >>> If process-shared semaphores really work, then the above structure is >>> not a pathological case. Effectively, sem_t is carved in stone. So >>> process-private semaphores should continue to have most of their stuff >>> in a separately allocated structure, to preserve flexibility. >>> >> There was an inadvertent race in FreeBSD's POSIX semaphores which I >> fixed in HEAD and STABLE about 6 weeks before 7.2 was released. >> >> I believe process-shared POSIX semaphores now work -- the Python >> 'multiprocessing' regression test now runs to completion with no errors >> on both HEAD and STABLE. > > The semaphores in recent 7 and 8 are definitely not process-shared (at least > not intentionally). They may work across a fork accidentally, but you can't > store it in an mmap() region and share it with an arbitrary process. > On a completely unrelated subject I was reading about PHP APC cache where they have the same need - cross-process locking with locks embedded in data structures and they have adopted userland spinlock code from PostgreSQL: http://www.scribd.com/doc/3288293/brian-shireapc-facebook (spin)locks are not the same as sempahores but maybe it will help the OP or anyone else trying to implement this feature: http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4&view=markup http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3&view=markup ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS isntall requirements
Willem Jan Withagen wrote:
Dmitry Morozovsky wrote:
On Sun, 7 Jun 2009, Willem Jan Withagen wrote:
WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote:
WJW> > KS> > Hi,
WJW> > KS> >
WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run
into:
WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib
WJW> > KS> > ===> sys/boot/i386/libi386 (install)
WJW> > KS> > ===> sys/boot/i386/libfirewire (install)
WJW> > KS> > ===> sys/boot/i386/loader (install)
WJW> > KS> > make: don't know how to make
WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop
WJW> > KS> KS> ISTR that the build was temporarily broken several days
ago.
WJW> > WJW> > WJW> > Well, according to http://tinderbox.freebsd.org/
it does not ;)
WJW> WJW> I'm not at all familiar with the intrinsics of the tinderbox
setup.
WJW> But am I free to assume that it is not tested with
'WITHOUT_ZFS=yes'???
WJW> WJW> Because that is required to have the trouble surface.
Ah well, you're possibly right. In the interim, you can safely
comment this line out, as there's nothing (except small amount of disk
space) you lose when you compile ZFS but do not use it.
I was trying to figure out if it was pilot error, or a bug.
But now I conclude it is a bug.
Should I log a PR?
--WjW
___
freebsd-stable@freebsd.org mailing list
http://lists.freeb, which is invalisd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
This bug exists from some time and has already be discussed on this list.
The bug stems from the use of the LIBZFS variable in
sys/boot/i386/loader/Makefile: it is not defined in this Makefile if
LOADER_ZFS_SUPPORT is not defined, so its value is taken from
share/mk/bsd.libnames.mk which is invalid in the WITHOUT_CDDL/WITHOUT_ZFS case.
Kip Macy said he would try to fix it by (last) Wednesday. He made a patch, then
reverted it (see the svn history).
You may use the attached simple patch.
Hope it helps,
Claude Buisson
--- sys/boot/i386/loader/Makefile.orig 2009-05-24 18:32:41.0 +0200
+++ sys/boot/i386/loader/Makefile 2009-06-01 15:18:57.0 +0200
@@ -18,7 +18,7 @@
# Put LOADER_ZFS_SUPPORT=yes in /etc/make.conf for ZFS support
.if defined(LOADER_ZFS_SUPPORT)
CFLAGS+= -DLOADER_ZFS_SUPPORT
-LIBZFS=${.OBJDIR}/../../zfs/libzfsboot.a
+LIBZFSBOOT=${.OBJDIR}/../../zfs/libzfsboot.a
.endif
# Enable PXE TFTP or NFS support, not both.
@@ -105,8 +105,8 @@
# XXX crt0.o needs to be first for pxeboot(8) to work
OBJS= ${BTXCRT}
-DPADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} ${LIBSTAND}
-LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} -lstand
+DPADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFSBOOT} ${LIBI386} ${LIBSTAND}
+LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFSBOOT} ${LIBI386} -lstand
.include
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS isntall requirements
Dmitry Morozovsky wrote: On Sun, 7 Jun 2009, Willem Jan Withagen wrote: WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: WJW> > KS> > Hi, WJW> > KS> > WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib WJW> > KS> > ===> sys/boot/i386/libi386 (install) WJW> > KS> > ===> sys/boot/i386/libfirewire (install) WJW> > KS> > ===> sys/boot/i386/loader (install) WJW> > KS> > make: don't know how to make WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop WJW> > KS> KS> ISTR that the build was temporarily broken several days ago. WJW> > WJW> > WJW> > Well, according to http://tinderbox.freebsd.org/ it does not ;) WJW> WJW> I'm not at all familiar with the intrinsics of the tinderbox setup. WJW> But am I free to assume that it is not tested with 'WITHOUT_ZFS=yes'??? WJW> WJW> Because that is required to have the trouble surface. Ah well, you're possibly right. In the interim, you can safely comment this line out, as there's nothing (except small amount of disk space) you lose when you compile ZFS but do not use it. I was trying to figure out if it was pilot error, or a bug. But now I conclude it is a bug. Should I log a PR? --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I need to add commands that starts every time at system boot.
2009/6/7 Clifton Royston : > On Sun, Jun 07, 2009 at 04:12:41PM -0400, Scott Ullrich wrote: >> On Sun, Jun 7, 2009 at 3:36 PM, Chris Rees wrote: >> > 2009/6/7 Clifton Royston : >> > >> >> If you feel you just *can't* do it via a script in >> >> /usr/local/etc/rc.d, which is the better way, add a script called >> >> /etc/rc.local and that will be run after all the other start-up steps. >> > >> > What's wrong with rc.local? >> >> Probably stems from this discussion: >> http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html > > No, I hadn't actually seen that discussion before. > > I used to work on BSD/OS, which had only the rc.local mechanism, and > when I first switched over to FreeBSD it was what I used. Eventually I > got my head around the /etc/rc.d and /usr/local/etc/rc.d mechanism and > found it distinctly superior, so now I use it almost exclusively. > > Major highlights as to why are: > > * You can readily implement whatever additional operations your service > should support, such as restart/shutdown/whatever; > * you can add or remove different services as discrete entities, > without having to merge their change or removal into a single text > file; > * the startup/shutdown script can therefore readily be packaged for > removal/installation together with any other software for the > service in question; > * you can get your service or operation run in a specific order > relative to other services; > * you can use the same script to start, shutdown, or restart the > service at another time if appropriate or necessary > > It used to be a little harder to write them than a few lines in > rc.local, but now sourcing rc_subr provides shell functions which make > it trivial. > > These days I only use rc.local if I need to do some kind of > non-critical quick hack, e.g. for troubleshooting a problem. > -- Clifton > > -- > Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > Nice, thanks a lot, didn't know about rc_subr. Thanks Scott too. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IBM TSM server
On Mon, Jun 8, 2009 at 9:16 AM, Wojciech Puchar < woj...@wojtek.tensor.gdynia.pl> wrote: > > the type fdisk /dev/da1 and then compare the sectors values with what dmesg > says > > fdisk /dev/ad2 : *** Working on device /dev/ad2 *** parameters extracted from in-core disklabel are: cylinders=155127 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155127 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 41929587 (20473 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 41929650, size 114430995 (55874 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 dmesg doesn't say anything usefull. only: ad2: 76351MB at ata1-master UDMA100 I'm not pretty good at this but it seams ok. the disk has been 99% full before and no problems. The slices were created a long time ago and ran some random test that all came out ok. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IBM TSM server
isn;t it trying to read past the end of disk? Hmm.. I guess you are correct. The question is why is it doing this ? because partition/slice table is wrong? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
