57 ZFS patches not merged to RELENG_7
Hi, I identified at least 57 patches which are in 8-stable, but not in 7-stable. Does someone know the status of those patches (listed below)? Maybe not all are applicable, but some of them should really get merged. I also have seen some things which I think are mismerges to 7-stable, but I do not have a list/diff of them at hand (I diffed 7-stable and 8-stable and those things where in the noise of the stuff which is not merged yet, one of the things I find directly now is two times the same line with kmem_cache_create of the zio_cache in cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c). If those people (ok, mostly pjd) which handle ZFS stuff normally do not have time to take care about this, are there people interested in helping me merge those things? Basically this means trying to apply the patches listed below on 7-stable, and testing them (or patches from other people, in case you are not able to merge a patch yourself) on a scratch box (I do not have a scratch-box with 7-stable around). It also means reviewing the patches regarding possible issues (I already identified some which need investigation, see below). Suggestions where those things should be coordinated in this case (on fs@ or stable@ or in the FreeBSD Wiki)? Below is the list of patches which I identified. I didn't had a look which one depends on which one, but there are for sure dependencies. The format is URL of the patch in head committer which committed it - my comment about the patch commit log Bye, Alexander. http://svn.freebsd.org/viewvc/base?view=revisionrevision=185310 ganbold - very easy merge ---snip--- Remove unused variable. Found with: Coverity Prevent(tm) CID: 3669,3671 ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=185319 pjd - applicable to RELENG_7? ---snip--- Fix locking (file descriptor table and Giant around VFS). ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=192689 trasz - very easy merge ---snip--- Fix comment. ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=193110 kmacy - easy merge ---snip--- work around snapshot shutdown race reported by Henri Hennebert ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=193128 kmacy - first probably, second and 3rd to check ---snip--- fix xdrmem_control to be safe in an if statement fix zfs to depend on krpc remove xdr from zfs makefile ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=193440 ps - shared vnode locks available in RELENG_7? vn_lock same syntax? ---snip--- Support shared vnode locks for write operations when the offset is provided on filesystems that support it. This really improves mysql + innodb performance on ZFS. ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=194043 kmacy - sysctl API change? ---snip--- pjd has requested that I keep the tunable as zfs_prefetch_disable to minimize gratuitous differences with Opensolaris' ZFS ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=195627 marcel - easy merge ---snip--- In nvpair_native_embedded_array(), meaningless pointers are zeroed. The programmer was aware that alignment was not guaranteed in the packed structure and used bzero() to NULL out the pointers. However, on ia64, the compiler is quite agressive in finding ILP and calls to bzero() are often replaced by simple assignments (i.e. stores). Especially when the width or size in question corresponds with a store instruction (i.e. st1, st2, st4 or st8). The problem here is not a compiler bug. The address of the memory to zero-out was given by 'packed-nvl_priv' and given the type of the 'packed' pointer the compiler could assume proper alignment for the replacement of bzero() with an 8-byte wide store to be valid. The problem is with the programmer. The programmer knew that the address did not have the alignment guarantees needed for a regular assignment, but failed to inform the compiler of that fact. In fact, the programmer told the compiler the opposite: alignment is guaranteed. The fix is to avoid using a pointer of type nvlist_t * and instead use a char * pointer as the basis for calculating the address. This tells the compiler that only 1-byte alignment can be assumed and the compiler will either keep the bzero() call or instead replace it with a sequence of byte-wise stores. Both are valid. ---snip--- http://svn.freebsd.org/viewvc/base?view=revisionrevision=195785 trasz - extattr_check_cred same sytax in RELENG_7? Necessary? ---snip--- Fix permission handling for extended attributes in ZFS. Without this change, ZFS uses SunOS Alternate Data Streams semantics - each EA has its own permissions, which are set at EA creation time and - unlike SunOS - invisible to the user and impossible to change. From the user point of view, it's just broken: sometimes access is granted when it shouldn't be, sometimes it's denied when it shouldn't be. This patch makes
Re: 57 ZFS patches not merged to RELENG_7
On 17/12/2009 7:03 PM, Alexander Leidinger wrote: Hi, I identified at least 57 patches which are in 8-stable, but not in 7-stable. [snip lots of updates] one more... http://www.freebsd.org/cgi/query-pr.cgi?pr=139076 ___ 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
Passenger hangs on live and SEGV on tests possible threading / kernel bug?
We're having an issue with Passenger on FreeBSD where it will hang and stop processing any more requests the details are attach to the following bug report: http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 In addition the test suite crashes in what seems to be a very basic test, which I'm at a loss with. http://code.google.com/p/phusion-passenger/issues/detail?id=441 I'm thinking this may be a bugs in the FreeBSD either kernel or thread library as the crashes don't make any sense from the application side. Any advise on debugging or feedback on the stack traces would be much appreciated. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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
iSCSI initiator and Dell PowerVault MD3000i
please Cc: me, I am not subscribed to freebsd-scsi Sossi Andrej wrote: On 16. 12. 2009 15:57, Miroslav Lachman wrote: [...] I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. But be careful to configure MD3000i. MD3000i assign by default first disk to preferred controller 0, second disk to preferred controller 1, third disk to preferred controller 0, and so on. First, third, fifth... disks is usable from FreeBSD, but second, fourth,... disks result unusable. Work around: manually assign all disks to controller 0. When you say unusable do you mean you can't access it at all / it errors even if it's the only path (drive) used? It would be normal if you have for example two paths to each drive and can't mount the other path if one path to the drive is mounted - this is not a usable combination. You can use geom_multipath to get multipath failover. I got errors even in unmounted state. I tried iscsi-2.2.3 and got same errors. I tried second path first (device da0) and it produces same errors, then I run iscontrol for the first path (device da1) and everything is fine. path throught second controller: ERROR # diskinfo -t /dev/da0 /dev/da0 512 # sectorsize 2998998663168 # mediasize in bytes (2.7T) 5857419264 # mediasize in sectors 364607 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke:diskinfo: read error or disk too small for test.: Invalid argument path throught first controller: OK # diskinfo -t /dev/da1 /dev/da1 512 # sectorsize 2998998663168 # mediasize in bytes (2.7T) 5857419264 # mediasize in sectors 364607 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 2.483517 sec =9.934 msec Half stroke: 250 iter in 2.575778 sec = 10.303 msec Quarter stroke: 500 iter in 2.926170 sec =5.852 msec Short forward:400 iter in 0.916901 sec =2.292 msec Short backward: 400 iter in 2.181790 sec =5.454 msec Seq outer: 2048 iter in 0.520920 sec =0.254 msec Seq inner: 2048 iter in 0.545300 sec =0.266 msec Transfer rates: outside: 102400 kbytes in 1.414997 sec =72368 kbytes/sec middle:102400 kbytes in 1.45 sec =70405 kbytes/sec inside:102400 kbytes in 1.422527 sec =71985 kbytes/sec Do you have experiences with iSCSI multipath? I read about geom_fox and gmultipath... Miroslav Lachman ___ 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: iSCSI initiator and Dell PowerVault MD3000i
2009/12/17 Miroslav Lachman 000.f...@quip.cz: please Cc: me, I am not subscribed to freebsd-scsi Sossi Andrej wrote: On 16. 12. 2009 15:57, Miroslav Lachman wrote: [...] I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. But be careful to configure MD3000i. MD3000i assign by default first disk to preferred controller 0, second disk to preferred controller 1, third disk to preferred controller 0, and so on. First, third, fifth... disks is usable from FreeBSD, but second, fourth,... disks result unusable. Work around: manually assign all disks to controller 0. When you say unusable do you mean you can't access it at all / it errors even if it's the only path (drive) used? It would be normal if you have for example two paths to each drive and can't mount the other path if one path to the drive is mounted - this is not a usable combination. You can use geom_multipath to get multipath failover. I got errors even in unmounted state. I tried iscsi-2.2.3 and got same errors. I tried second path first (device da0) and it produces same errors, then I run iscontrol for the first path (device da1) and everything is fine. path throught second controller: ERROR # diskinfo -t /dev/da0 /dev/da0 512 # sectorsize 2998998663168 # mediasize in bytes (2.7T) 5857419264 # mediasize in sectors 364607 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: diskinfo: read error or disk too small for test.: Invalid argument path throught first controller: OK # diskinfo -t /dev/da1 /dev/da1 512 # sectorsize 2998998663168 # mediasize in bytes (2.7T) 5857419264 # mediasize in sectors 364607 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 2.483517 sec = 9.934 msec Half stroke: 250 iter in 2.575778 sec = 10.303 msec Quarter stroke: 500 iter in 2.926170 sec = 5.852 msec Short forward: 400 iter in 0.916901 sec = 2.292 msec Short backward: 400 iter in 2.181790 sec = 5.454 msec Seq outer: 2048 iter in 0.520920 sec = 0.254 msec Seq inner: 2048 iter in 0.545300 sec = 0.266 msec Transfer rates: outside: 102400 kbytes in 1.414997 sec = 72368 kbytes/sec middle: 102400 kbytes in 1.45 sec = 70405 kbytes/sec inside: 102400 kbytes in 1.422527 sec = 71985 kbytes/sec This is strange and probably indicates a bug somewhere. Can you check your SAN configuration for example, wrong access permissions assigned to the problematic port? Do you have experiences with iSCSI multipath? I read about geom_fox and gmultipath... You should probably skip geom_fox and just use gmultipath. It works as advertised, nothing fancy to report. ___ 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: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: We're having an issue with Passenger on FreeBSD where it will hang and stop processing any more requests the details are attach to the following bug report: http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 In addition the test suite crashes in what seems to be a very basic test, which I'm at a loss with. http://code.google.com/p/phusion-passenger/issues/detail?id=441 I'm thinking this may be a bugs in the FreeBSD either kernel or thread library as the crashes don't make any sense from the application side. Any advise on debugging or feedback on the stack traces would be much appreciated. For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? For example: # cd /usr/src/lib/libc # make clean # make DEBUG_FLAGS=-g # make DEBUG_FLAGS=-g install However, if you are hanging in read(), that usually means you have a socket that just doesn't have data. That might be an application bug of some sort. The segv trace doesn't include the first part of GDB messages which show which thread actually had a seg fault. It looks like it was the thread that was throwing an exception. However, nanosleep() doesn't throw exceptions, so that stack trace doesn't really make sense either. Perhaps that stack is hosed by the exception handling code? -- 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: iSCSI initiator and Dell PowerVault MD3000i
Sossi Andrej wrote: [...] I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine. But be careful to configure MD3000i. MD3000i assign by default first disk to preferred controller 0, second disk to preferred controller 1, third disk to preferred controller 0, and so on. First, third, fifth... disks is usable from FreeBSD, but second, fourth,... disks result unusable. Work around: manually assign all disks to controller 0. I'm talking with Dell's technical support, but Dell not support FreeBSD! In any case, technical support tell me, the problem (maybe) is the multipath. FreeBSD use only one path (only one IP) to communicate to MD3000i. Second net interface in unused. I hope that I have been helpful. It was helpful! You are right, that MD Storage Manager set preferred controller path to 0 for odd Virtual Disks and 1 to even Virtual Disks. (I don't know why) And if I manually changed it to controller 0, I can access it by this preferred path, but can't access it by the other path. Does it mean I can't use multipath feature? Or what is the right behavior of this preferred path settings? Miroslav Lachman ___ 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: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
On Thu, 17 Dec 2009, John Baldwin wrote: On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: We're having an issue with Passenger on FreeBSD where it will hang and stop processing any more requests the details are attach to the following bug report: http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 In addition the test suite crashes in what seems to be a very basic test, which I'm at a loss with. http://code.google.com/p/phusion-passenger/issues/detail?id=441 I'm thinking this may be a bugs in the FreeBSD either kernel or thread library as the crashes don't make any sense from the application side. Any advise on debugging or feedback on the stack traces would be much appreciated. For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? Yes, good advice, I have noticed that you can't trust GDB stack traces unless libc and libthr have been built with debug (-g) enabled. -- DE ___ 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: iSCSI initiator and Dell PowerVault MD3000i
please Cc: me, I am not subscribed to freebsd-scsi
Sossi Andrej wrote:
On 16. 12. 2009 15:57, Miroslav Lachman wrote:
[...]
I use MD300i with FreeBSD 7.0 and 7.1 with iscsi-2.2.2. It work fine.
But be careful to configure MD3000i. MD3000i assign by default first
disk to preferred controller 0, second disk to preferred controller 1,
third disk to preferred controller 0, and so on. First, third, fifth...
disks is usable from FreeBSD, but second, fourth,... disks result
unusable.
Work around: manually assign all disks to controller 0.
When you say unusable do you mean you can't access it at all / it
errors even if it's the only path (drive) used? It would be normal if
you have for example two paths to each drive and can't mount the other
path if one path to the drive is mounted - this is not a usable
combination. You can use geom_multipath to get multipath failover.
I got errors even in unmounted state.
I tried iscsi-2.2.3 and got same errors. I tried second path first
(device da0) and it produces same errors, then I run iscontrol for the
first path (device da1) and everything is fine.
path throught second controller: ERROR
# diskinfo -t /dev/da0
/dev/da0
512 # sectorsize
2998998663168 # mediasize in bytes (2.7T)
5857419264 # mediasize in sectors
364607 # Cylinders according to firmware.
255 # Heads according to firmware.
63 # Sectors according to firmware.
Seek times:
Full stroke:diskinfo: read error or disk too small for
test.: Invalid argument
path throught first controller: OK
# diskinfo -t /dev/da1
/dev/da1
512 # sectorsize
2998998663168 # mediasize in bytes (2.7T)
5857419264 # mediasize in sectors
364607 # Cylinders according to firmware.
255 # Heads according to firmware.
63 # Sectors according to firmware.
Seek times:
Full stroke: 250 iter in 2.483517 sec =9.934 msec
Half stroke: 250 iter in 2.575778 sec = 10.303 msec
Quarter stroke: 500 iter in 2.926170 sec =5.852 msec
Short forward:400 iter in 0.916901 sec =2.292 msec
Short backward: 400 iter in 2.181790 sec =5.454 msec
Seq outer: 2048 iter in 0.520920 sec =0.254 msec
Seq inner: 2048 iter in 0.545300 sec =0.266 msec
Transfer rates:
outside: 102400 kbytes in 1.414997 sec =72368
kbytes/sec
middle:102400 kbytes in 1.45 sec =70405
kbytes/sec
inside:102400 kbytes in 1.422527 sec =71985
kbytes/sec
the numbers seem ok to me, concidering that the net is 1Gb.
can you configure the target virtual disk to have luns?
in any case the errors seem to be in the md3000i, can you see/check its
error log?
Do you have experiences with iSCSI multipath? I read about geom_fox and
gmultipath...
i have no experience with it, and personaly see no benefit in it (but then
others might disagree :-)
danny
___
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: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
- Original Message - From: John Baldwin j...@freebsd.org For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? For example: # cd /usr/src/lib/libc # make clean # make DEBUG_FLAGS=-g # make DEBUG_FLAGS=-g install However, if you are hanging in read(), that usually means you have a socket that just doesn't have data. That might be an application bug of some sort. The segv trace doesn't include the first part of GDB messages which show which thread actually had a seg fault. It looks like it was the thread that was throwing an exception. However, nanosleep() doesn't throw exceptions, so that stack trace doesn't really make sense either. Perhaps that stack is hosed by the exception handling code? I've uploaded a two more traces for the oxt test failure / segv. http://code.google.com/p/phusion-passenger/issues/detail?id=441#c1 From looking at the test case it testing the capture of failures and its ability to create a stack trace output so that may give others some indication where the issue may be? I will look to do the same on for the hang issue but that's on a live site so will need to schedule some downtime before I can get those rebuilt and then wait for it to hang again, which could be quite some time :( Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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_8_0 tinderbox] failure on i386/i386
TB --- 2009-12-17 16:08:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-12-17 16:08:01 - starting RELENG_8_0 tinderbox run for i386/i386 TB --- 2009-12-17 16:08:01 - cleaning the object tree TB --- 2009-12-17 16:08:25 - cvsupping the source tree TB --- 2009-12-17 16:08:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_0/i386/i386/supfile TB --- 2009-12-17 16:08:57 - building world TB --- 2009-12-17 16:08:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-17 16:08:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-17 16:08:57 - TARGET=i386 TB --- 2009-12-17 16:08:57 - TARGET_ARCH=i386 TB --- 2009-12-17 16:08:57 - TZ=UTC TB --- 2009-12-17 16:08:57 - __MAKE_CONF=/dev/null TB --- 2009-12-17 16:08:57 - cd /src TB --- 2009-12-17 16:08:57 - /usr/bin/make -B buildworld World build started on Thu Dec 17 16:08:58 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 Thu Dec 17 17:08:01 UTC 2009 TB --- 2009-12-17 17:08:01 - generating LINT kernel config TB --- 2009-12-17 17:08:01 - cd /src/sys/i386/conf TB --- 2009-12-17 17:08:01 - /usr/bin/make -B LINT TB --- 2009-12-17 17:08:01 - building LINT kernel TB --- 2009-12-17 17:08:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-12-17 17:08:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-12-17 17:08:01 - TARGET=i386 TB --- 2009-12-17 17:08:01 - TARGET_ARCH=i386 TB --- 2009-12-17 17:08:01 - TZ=UTC TB --- 2009-12-17 17:08:01 - __MAKE_CONF=/dev/null TB --- 2009-12-17 17:08:01 - cd /src TB --- 2009-12-17 17:08:01 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Dec 17 17:08:01 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 -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -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 -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsocket.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -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 -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdstate.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -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 -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsubs.c /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsubs.c: In function 'nfsrv_fillattr': /src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdsubs.c:1351: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /src/sys/modules/nfsd. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-12-17 17:27:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-12-17 17:27:59 - ERROR: failed to build lint kernel TB --- 2009-12-17 17:27:59 - 3641.49 user
Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
Steven Hartland wrote: I will look to do the same on for the hang issue but that's on a live site so will need to schedule some downtime before I can get those rebuilt and then wait for it to hang again, which could be quite some time :( Actually, you can rebuild it *and* reinstall libc and libthr on a live system, if it's the same version of course. Already running processes will run off a deleted file (inode will still be there) and new processes will, since it's the same version, not notice anything is different. The only downtime you will have is the time required to restart your application. ___ 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: RELENG_7: gdm after portupgrade does not allow logins
Am 17.12.2009, 02:09 Uhr, schrieb Dmitry Morozovsky ma...@rinet.ru:
Dear colleagues,
after portupgrade'ing on last gnome update I have very strange situation:
gdm does not show neither login list not username text field; after
pressing
space, some unlabelled text field opens (symbols are echoed, so I
suppose it's
like login name field); however, entering anything there does not lead
anywhere.
portupgrade -f gdm does not help; portupgrade -f ${direct gdm
dependencies}
does not help, either.
And, of course, I even rebooted the machine without a bit of success.
Any hints? Thanks in advance!
Make sure that /proc is mounted, see the GNOME FAQ for details on how to
set /etc/fstab to make that happen automatically on boot.
--
Matthias Andree
___
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
