MacPro 2009 again
Hello all, I come back on FreeBSD. I tried for a couple of months macports, fink on macosx on Mavericks version but it is not the same. On Mavericks we can have X via XQuartz but I miss some softwares and X from FreeBSD is different. So my actual solution is: Use one system with my needs and boot on when it's useful. I have many request about FreeBSD on MacPro (to access to my macintosh hard drive inside FreeBSD for instance). But first I want to boot on my FreeBSD HD. I installed on a hard drive who had previously the FileVault turned on. I want to know if it is the cause of my problem. Because I previously wrote gpart bootcode -b /boot/pmbr -p /boot/gptboot -i bootpartition adax and fix bless -device /dev/disk setboot -legacy]. and my system refuses to boot. The last command ask me a problem. Do I need to bless the whole disk or the boot partition of disk ? Nicolas Kozic ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: MacPro 2009 again
On 03/12/14 09:25, Nicolas Kozic wrote: Hello all, I come back on FreeBSD. I tried for a couple of months macports, fink on macosx on Mavericks version but it is not the same. On Mavericks we can have X via XQuartz but I miss some softwares and X from FreeBSD is different. So my actual solution is: Use one system with my needs and boot on when it's useful. I have many request about FreeBSD on MacPro (to access to my macintosh hard drive inside FreeBSD for instance). But first I want to boot on my FreeBSD HD. I installed on a hard drive who had previously the FileVault turned on. I want to know if it is the cause of my problem. Because I previously wrote gpart bootcode -b /boot/pmbr -p /boot/gptboot -i bootpartition adax and fix bless -device /dev/disk setboot -legacy]. and my system refuses to boot. The last command ask me a problem. Do I need to bless the whole disk or the boot partition of disk ? Nicolas Kozic Hi, I've only got MBR partition layout to work with MBPro x86 based ones. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help
From b...@0x20.net Thu Mar 6 22:02:56 2014 On Thu, Mar 06, 2014 at 12:59:14AM -0800, Anton Shterenlikht wrote: In my initial PR (sparc64 r261798), http://www.freebsd.org/cgi/query-pr.cgi?pr=187080 I said that rsync was triggering this panic. While true, I now see that there's more to it. I disabled the rsync, and the cron jobs. Still I get exactly the same panic every night at 03:02: # grep Dumptime /var/crash/* /var/crash/info.0: Dumptime: Wed Feb 26 10:10:51 2014 /var/crash/info.1: Dumptime: Thu Feb 27 03:02:14 2014 /var/crash/info.2: Dumptime: Fri Feb 28 03:02:29 2014 /var/crash/info.3: Dumptime: Sat Mar 1 03:02:25 2014 /var/crash/info.4: Dumptime: Tue Mar 4 03:02:01 2014 /var/crash/info.5: Dumptime: Wed Mar 5 03:02:05 2014 /var/crash/info.6: Dumptime: Thu Mar 6 03:02:11 2014 /var/crash/info.last: Dumptime: Thu Mar 6 03:02:11 2014 # This is likely triggered by one of the daily periodic scipts, after about 1 min from start: # grep daily /etc/crontab # Perform daily/weekly/monthly maintenance. 1 3 * * * rootperiodic daily # but which one? Some time ago I had a similar problem with 8.x. Setting vm.kmem_size=512M vm.kmem_size_max=512M in loader.conf helped. It's just a wild guess but might help. This didn't make any difference. However, I noticed that the panics were happening more and more often. I started suspecting a disk failure, so decided to do a full integrity check with dd, got: 17054+0 records in 17054+0 records out 17882415104 bytes transferred in 1035.889679 secs (17262857 bytes/sec) (ada1:ata2:0:1:0): READ_DMA. ACB: c8 00 80 93 9c 42 00 00 00 00 00 00 (ada1:ata2:0:1:0): CAM status: ATA Status Error (ada1:ata2:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) (ada1:ata2:0:1:0): RES: 51 40 21 94 9c 02 02 00 00 00 00 (ada1:ata2:0:1:0): Retrying command (ada1:ata2:0:1:0): READ_DMA. ACB: c8 00 80 93 9c 42 00 00 00 00 00 00 (ada1:ata2:0:1:0): CAM status: ATA Status Error (ada1:ata2:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) (ada1:ata2:0:1:0): RES: 51 40 21 94 9c 02 02 00 00 00 00 (ada1:ata2:0:1:0): Retrying command (ada1:ata2:0:1:0): READ_DMA. ACB: c8 00 80 93 9c 42 00 00 00 00 00 00 (ada1:ata2:0:1:0): CAM status: ATA Status Error (ada1:ata2:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) (ada1:ata2:0:1:0): RES: 51 40 21 94 9c 02 02 00 00 00 00 (ada1:ata2:0:1:0): Retrying command (ada1:ata2:0:1:0): READ_DMA. ACB: c8 00 80 93 9c 42 00 00 00 00 00 00 (ada1:ata2:0:1:0): CAM status: ATA Status Error (ada1:ata2:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) (ada1:ata2:0:1:0): RES: 51 40 21 94 9c 02 02 00 00 00 00 (ada1:ata2:0:1:0): Retrying command (ada1:ata2:0:1:0): READ_DMA. ACB: c8 00 80 93 9c 42 00 00 00 00 00 00 (ada1:ata2:0:1:0): CAM status: ATA Status Error (ada1:ata2:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) (ada1:ata2:0:1:0): RES: 51 40 21 94 9c 02 02 00 00 00 00 (ada1:ata2:0:1:0): Error 5, Retries exhausted dd: /dev/ada1b: Input/output error I guess the disk is fucked, right? Given that it's about 10 years old, this is not surprising. Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: lockmgr still held [tmpfs] [vm_map_remove()-vdropl()] (r262186: Thu Feb 20)
On 3/5/2014 1:50 PM, Konstantin Belousov wrote:
On Wed, Mar 05, 2014 at 02:21:04PM -0500, John Baldwin wrote:
On Wednesday, March 05, 2014 6:07:23 am Konstantin Belousov wrote:
On Wed, Mar 05, 2014 at 11:41:24AM +0200, Andriy Gapon wrote:
on 04/03/2014 18:45 John Baldwin said the following:
So I'm not sure how to fix this. The crash is in this code in
vm_object_deallocate():
if (object-type == OBJT_SWAP
(object-flags OBJ_TMPFS) != 0) {
vp = object-un_pager.swp.swp_tmpfs;
vhold(vp);
VM_OBJECT_WUNLOCK(object);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
vdrop(vp);
VM_OBJECT_WLOCK(object);
if (object-type == OBJT_DEAD ||
object-ref_count != 1) {
VM_OBJECT_WUNLOCK(object);
VOP_UNLOCK(vp, 0);
return;
}
if ((object-flags OBJ_TMPFS) != 0)
VOP_UNSET_TEXT(vp);
VOP_UNLOCK(vp, 0);
}
The vdrop() is dropping the count to zero and trying to free the vnode.
The
real problem I think is that swp_tmpfs doesn't have an implicit vhold()
on the
vnode, so in this case, the code is doing a vhold/vn_lock/vdrop of an
already-
free vnode. For OBJT_VNODE objects, the reference from the object back
to the
vnode holds a vref() that gets released by a vput() in
vm_object_vndeallocate().
One fix might be to chagne smp_tmpfs to hold a vhold reference. This is
untested but might work (but I'm also not sure that this is the right
thing in
that I don't know what other effects it might have).
I agree with your analysis, but I don't think that a filesystem holding
its own
vnode is a good idea. If I am not mistaken, that would prevent tmpfs
vnodes
from going to free list.
I'd rather try to modify vm_object_deallocate() code. E.g. vdrop() could
be
called after VOP_UNLOCK(). Alternatively, the code could handle a doomed
vnode
in a different way.
I agree with Andrey, it is just a bug to vdrop() before unlock.
Please try this.
Ok, my only worry is in the case of Bryan's panic, the hold count on the
vnode
was already zero before vhold() was called, so is it possible that it is a
stale
pointer or is there some other implicit reference that prevents that? If it
can't
be stale, I think deferring the vdrop() is fine.
The object-un_pager.swp.swp_tmpfs is cleared under the object lock
before the vnode is reclaimed, i.e. long before the vnode can be freed.
swp_tmpfs should be kept in sync with the OBJ_TMPFS flag, so the
vhold() is safe while flag is set and object is locked.
This has been stable. Not sure if it fixes the original problem, but I
have not seen any panics since using it and doing many poudriere builds.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
[head tinderbox] failure on powerpc/powerpc
TB --- 2014-03-12 17:29:55 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-03-12 17:29:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-12 17:29:55 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-03-12 17:29:55 - cleaning the object tree TB --- 2014-03-12 17:29:55 - /usr/local/bin/svn stat /src TB --- 2014-03-12 17:29:58 - At svn revision 263090 TB --- 2014-03-12 17:29:59 - building world TB --- 2014-03-12 17:29:59 - CROSS_BUILD_TESTING=YES TB --- 2014-03-12 17:29:59 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-12 17:29:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-12 17:29:59 - SRCCONF=/dev/null TB --- 2014-03-12 17:29:59 - TARGET=powerpc TB --- 2014-03-12 17:29:59 - TARGET_ARCH=powerpc TB --- 2014-03-12 17:29:59 - TZ=UTC TB --- 2014-03-12 17:29:59 - __MAKE_CONF=/dev/null TB --- 2014-03-12 17:29:59 - cd /src TB --- 2014-03-12 17:29:59 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Mar 12 17:30:06 UTC 2014 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclanglex/../../../contrib/llvm/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/src/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\powerpc-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\powerpc-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp -o PPMacroExpansion.o c++ -O2 -pipe -I/src/lib/clang/libclanglex/../../../contrib/llvm/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/src/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\powerpc-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\powerpc-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp -o PTHLexer.o c++ -O2 -pipe -I/src/lib/clang/libclanglex/../../../contrib/llvm/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/src/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\powerpc-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\powerpc-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp -o Pragma.o /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp: In member function 'void clang::Preprocessor::HandlePragmaIncludeAlias(clang::Token)': /src/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp:622: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.freebsd.org/send-pr.html for instructions. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/clang/libclanglex *** Error code 1 Stop. bmake[4]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-03-12 18:32:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-12 18:32:29 - ERROR: failed to build world TB --- 2014-03-12 18:32:29 - 3066.73 user 504.48 system 3754.35 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
sem_wait(3) is not always a cancellation point
-current: From my understand of POSIX, sem_wait(3) should always be a cancellation point. However, when the semaphore's count is positive and the caller successfully decrements the count, sem_wait(3) does not call _pthread_testcancel(), so it's not a cancellation point. See this totally contrived test case: http://www.vangyzen.net/FreeBSD/patches/sem_wait_cancel.c This patch seems like an appropriate fix: http://www.vangyzen.net/FreeBSD/patches/sem_wait_cancel.diff It adds a call to _pthread_testcancel() in the same location as _libc_sem_timedwait_compat() in libc/gen/sem.c. Is this a real bug, or am I missing something? Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
vm_map.h
The two defines in vm/vm_map.h #define min_offset header.start /* (c) */ #define max_offset header.end /* (c) */ are really getting in the way because those words are most likely to be used downstream. I would suggest renaming those defines to: #define vm_min_offset header.start /* (c) */ #define vm_max_offset header.end /* (c) */ Am I missing something? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
