Re: 7.1-RC2: link_elf: symbol cp_time undefined
On Dec 25, 2008, at 17:36, Jan Henrik Sylvester wrote: Garrett Cooper wrote: On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: During boot I see: link_elf: symbol cp_time undefined I have realized it now with RC2, but looking at my logs, I have had that message during boot since upgrading this machine from 7.0- RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile kernel modules from ports: fusefs-kmod and kqemu-kmod.) What is the easiest way to find out what tried to link to the unknown symbol? The context in which the messages appear is: savecore: no dumps found Initial i386 initialization:. Additional ABI support: linux. Starting local daemons:kldload: can't load ntfs: File exists link_elf: symbol cp_time undefined kldload: can't load linprocfs: No such file or directory link_elf: symbol cp_time undefined mount: linprocfs : Operation not supported by device . Updating motd. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Mounting late file systems:. In my rc.local, I have kldload ntfs kldload linprocfs mount -t linprocfs linprocfs /usr/compat/linux/proc which used to work (I think). /boot/kernel/linprocfs.ko does exist. Cheers, Jan Henrik Did you compile your kernel from scratch? -Garrett No, it came with freebsd-update (every possible freebsd-update since the install from the 7.0-BETA4 CD). Outside /etc, the IDS function of freebsd-update only reports a mismatch for /boot/kernel/ linker.hints -- can this be the problem? (I will try to replace it tomorrow.) Cheers, Jan Henrik It shouldn't be the hints file. I would think it's a lack of Linux support built into the updated kernel. I've never used freebsd-upgrade though.. -Garrett ___ 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: amd(8) cores dump when load high
On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric wrote: > Dear listers, > > We currently found that amd frequently cores dump while loading is > high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to > 7.1-PRERELEASE. > > I have read -stable and svn log of 7-STABLE, but can not found a > report or a solution. Did anyone have the same issue? Thank you very > much. > According to my previous experience, amd 6.1.5 crashes under low memory situations. Not necessary high load. Regards, Rong-En Fan ___ 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: process stuck in vmopar
Hi again! 2008/12/24 pluknet : > 2008/12/24 pluknet : >> 2008/12/24 pluknet : >>> 2008/12/24 pluknet : Server version: Apache/2.2.11 (Unix) built from sources. After issuing kill -9 process stuck in vmopar state forever. aaa301 2313 0.0 0.0 0 8 ?? DE3:10PM 0:00.01 /home/aaa301/myb vmopar System: FreeBSD 6.2 i386. >>> >>> One important note. >>> Kernel is built with options QUOTA, and this problem triggered >>> only when this user is overquoted (usage > quota and limit). >> >> A bit later various processes begin to stuck in "ufs" state. > > backtrace of process that stucks in vmopar: > > db> bt 1385 > Tracing pid 1385 tid 100181 td 0xc6c19960 > sched_switch(c6c19960,0,1) at sched_switch+0x15b > mi_switch(1,0) at mi_switch+0x270 > sleepq_switch(c2954ec8,c0a3d0a0,0,c094c4eb,211,...) at sleepq_switch+0xc1 > sleepq_wait(c2954ec8,0,c096897c,709,c096897c,...) at sleepq_wait+0x46 > msleep(c2954ec8,c0ab8e80,244,c0968ca9,0,c9030444,0,c0968eb0,200,c2954ec8,82) > at > msleep+0x279 > vm_page_sleep_if_busy(c2954ec8,1,c0968ca9) at vm_page_sleep_if_busy+0x7c > vm_object_page_remove(c9030444,4,0,8000,0,0) at vm_object_page_remove+0xf9 > vnode_pager_setsize(c903c000,4000,0) at vnode_pager_setsize+0xbd > ffs_write(f734a78c) at ffs_write+0x264 > VOP_WRITE_APV(c0a09b00,f734a78c) at VOP_WRITE_APV+0x112 > vnode_pager_generic_putpages(c903c000,f734a8d0,9000,5,f734a860,...) at > vnode_pag > er_generic_putpages+0x1ef > vop_stdputpages(f734a814) at vop_stdputpages+0x1a > VOP_PUTPAGES_APV(c0a09b00,f734a814) at VOP_PUTPAGES_APV+0x8c > vnode_pager_putpages(c9030444,f734a8d0,9,5,f734a860) at > vnode_pager_putpages+0x7 >e > vm_pageout_flush(f734a8d0,9,5,0,0,...) at vm_pageout_flush+0x112 > vm_object_page_collect_flush(c9030444,c29505a8,251,5,4a,...) at > vm_object_page_c >ollect_flush+0x2a0 > vm_object_page_clean(c9030444,0,0,0,0,...) at vm_object_page_clean+0x184 > vm_object_terminate(c9030444) at vm_object_terminate+0x60 > vnode_destroy_vobject(c903c000,c6973500,f734aab8,c6c19960,0,...) at > vnode_destro >y_vobject+0x39 > ufs_reclaim(f734aab8) at ufs_reclaim+0x46 > VOP_RECLAIM_APV(c0a09b00,f734aab8) at VOP_RECLAIM_APV+0x7e > vgonel(c903c000) at vgonel+0x12d > vrecycle(c903c000,c6c19960) at vrecycle+0x38 > ufs_inactive(f734ab40) at ufs_inactive+0x2af > VOP_INACTIVE_APV(c0a09b00,f734ab40) at VOP_INACTIVE_APV+0x7e > vinactive(c903c000,c6c19960) at vinactive+0x72 > vrele(c903c000,c9030444,0,c096897c,1a2,...) at vrele+0x14a > vm_object_vndeallocate(c9030444) at vm_object_vndeallocate+0xc0 > vm_object_deallocate(c9030444,c9030444,0,c0968016,8e7) at > vm_object_deallocate+0 > xb3 > vm_map_entry_delete(c722a000,c7194bf4,f734ac20,c081ca37,c722a000,...) > at vm_map_ > entry_delete+0x130 > vm_map_delete(c722a000,0,bfc0) at vm_map_delete+0x18f > vmspace_exit(c6c19960,c0a4bde0,0,c09463ea,125,...) at vmspace_exit+0xd5 > exit1(c6c19960,9,2831a4b4,c6c19960,c7234000,...) at exit1+0x496 > sigexit(c6c19960,9,c7234aa8,0,c09499bc,...) at sigexit+0xdf > postsig(9) at postsig+0x160 > ast(f734ad38) at ast+0x35e > doreti_ast() at doreti_ast+0x17 > > db> show alllock > Process 1385 (httpd) thread 0xc6c19960 (100181) > exclusive sx user map r = 0 (0xc722a044) locked @ > /usr/src/sys_uvmem_uip.6.2_RELEASE/vm/vm_map.c:307 > Today I found some interesting details how to reproduce my problem. Stucking apache2.x in "vmopar" with subsequent stuck of other various processes in "ufs" is only triggered with those options enabled in php.ini: extension="xcache.so" xcache.size=64M xcache.count=8 xcache.slot=64K xcache.var_size=64M xcache.var_count=8 xcache.var_slots=64K xcache.mmap_path=/tmp/xcache Perhaps the problem is related to mmap vs threads interaction. Any thoughts? > -- > wbr, > pluknet > ___ 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: 7.1-RC2: link_elf: symbol cp_time undefined
Garrett Cooper wrote: On Dec 25, 2008, at 17:36, Jan Henrik Sylvester wrote: Garrett Cooper wrote: On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: During boot I see: link_elf: symbol cp_time undefined I have realized it now with RC2, but looking at my logs, I have had that message during boot since upgrading this machine from 7.0-RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile kernel modules from ports: fusefs-kmod and kqemu-kmod.) What is the easiest way to find out what tried to link to the unknown symbol? The context in which the messages appear is: savecore: no dumps found Initial i386 initialization:. Additional ABI support: linux. Starting local daemons:kldload: can't load ntfs: File exists link_elf: symbol cp_time undefined kldload: can't load linprocfs: No such file or directory link_elf: symbol cp_time undefined mount: linprocfs : Operation not supported by device . Updating motd. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Mounting late file systems:. In my rc.local, I have kldload ntfs kldload linprocfs mount -t linprocfs linprocfs /usr/compat/linux/proc which used to work (I think). /boot/kernel/linprocfs.ko does exist. Cheers, Jan Henrik Did you compile your kernel from scratch? -Garrett No, it came with freebsd-update (every possible freebsd-update since the install from the 7.0-BETA4 CD). Outside /etc, the IDS function of freebsd-update only reports a mismatch for /boot/kernel/linker.hints -- can this be the problem? (I will try to replace it tomorrow.) Cheers, Jan Henrik It shouldn't be the hints file. I would think it's a lack of Linux support built into the updated kernel. I've never used freebsd-upgrade though.. -Garrett Thanks for your answer. The problem is entirely my fault. From 7.0, I still had /boot/ulegeneric in my kern.module_path instead of /boot/kernel -- and /boot/ulegeneric is still there containing a 7.0-p6 kernel with ULE scheduler, of which the modules do not work with the 7.1-RC2 kernel (booted from /boot/kernel). Sorry for the fuss. Cheers, Jan Henrik ___ 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"
Fatal trap 12: page fault while in kernel mode (swi6: task queue)
Can anyone help understanding the reason?
# uname -rsm
FreeBSD 6.4-STABLE i386
# kgdb kernel.debug /var/crash/vmcore.7
GNU gdb 6.1.1 [FreeBSD]
Copyright
2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU
General Public License, and you are
welcome to change it and/or distribute
copies of it under certain conditions.
Type "show copying" to see the
conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd"...
Unread portion of
the kernel message buffer:
acd0: WARNING - PREVENT_ALLOW read data overrun 18>0
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in
kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x104
fault code =
supervisor read, page not present
instruction pointer = 0x20:0xc0541da5
stack
pointer = 0x28:0xe5928c00
frame pointer = 0x28:0xe5928c18
code
segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran
1
processor eflags= resume, IOPL = 0
current process = 17 (swi6: task queue)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 4h16m22s
Physical memory:
2031 MB
Dumping 204 MB: 189 173 157 141 125 109 93 77 61 45 29 13
Reading
symbols from /boot/kernel/linux.ko...done.
Loaded symbols for
/boot/kernel/linux.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from
/boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading
symbols from /boot/kernel/linprocfs.ko...done.
Loaded symbols for
/boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/logo_saver.ko...
done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0 doadump () at pcpu.h:
165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0
doadump () at pcpu.h:165
#1 0xc054d7d9 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
#2 0xc054dba6 in panic (fmt=0xc0736cc9 "%
s") at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc071812c in trap_fatal
(frame=0xe5928bc0, eva=0) at /usr/src/sys/i386/i386/trap.c:838
#4 0xc07177e4
in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -960560384,
tf_esi = 4, tf_ebp = -443380712, tf_isp = -443380756, tf_ebx = -942867596,
tf_edx = 6, tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip =
-1068229211, tf_cs = 32, tf_eflags = 65538, tf_esp = -942867596, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:270
#5 0xc06ff98a in calltrap () at
/usr/src/sys/i386/i386/exception.s:139
#6 0xc0541da5 in _mtx_lock_sleep
(m=0xc7ccfb74, tid=3334406912, opts=0, file=0x0, line=0) at
/usr/src/sys/kern/kern_mutex.c:546
#7 0xc054ca79 in _sema_post
(sema=0xc7ccfb74, file=0x0, line=0) at /usr/src/sys/kern/kern_sema.c:79
#8
0xc04705e3 in ata_completed (context=0xc7ccfb28, dummy=1) at
/usr/src/sys/dev/ata/ata-queue.c:481
#9 0xc057547d in taskqueue_run
(queue=0xc6c8a000) at /usr/src/sys/kern/subr_taskqueue.c:257
#10 0xc0575793 in
taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:299
#11
0xc052ff1b in ithread_execute_handlers (p=0xc6bef860, ie=0xc6c44e80) at
/usr/src/sys/kern/kern_intr.c:682
#12 0xc0530077 in ithread_loop
(arg=0xc6c62510) at /usr/src/sys/kern/kern_intr.c:766
#13 0xc052e800 in
fork_exit (callout=0xc0530010 , arg=0x1, frame=0x1) at
/usr/src/sys/kern/kern_fork.c:788
#14 0xc06ff9ec in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:208
(kgdb) frame 6
#6 0xc0541da5 in
_mtx_lock_sleep (m=0xc7ccfb74, tid=3334406912, opts=0, file=0x0, line=0) at
/usr/src/sys/kern/kern_mutex.c:546
546 owner = (struct thread *)(v &
MTX_FLAGMASK);
(kgdb) list
541 #if defined(SMP) && !defined
(NO_ADAPTIVE_MUTEXES)
542 /*
543 * If the current owner of the lock is
executing on another
544 * CPU, spin instead of blocking.
545 */
546
owner = (struct thread *)(v & MTX_FLAGMASK);
547 #ifdef ADAPTIVE_GIANT
548 if
(TD_IS_RUNNING(owner)) {
549 #else
550 if (m != &Giant && TD_IS_RUNNING
(owner)) {
___
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"
Kernel Trap during installworld caused unrecoverable system
Hi folks. I was unfortunate enough to encounter a kernel trap in single user mode yesterday when upgrading from 7.1-RC1 to -RC2 using the typical build/install world. I'm still not sure what caused the trap, as the system was rebooting when I saw the screen. As one would expect, this led to an irrecoverable system; the system would automatically drop me into single user mode, as it could only mount the root directory; /bin/sh and /bin/csh would not work (had to use /restore/csh for the minimal digging I actually could do). So, now to the question. Given I could not mount anything other than /, would there have been any way for me to gather debugging information on what caused this failure? (FWIW, I am certain it is not a hardware failure.) Regards, -- Glen Barber ___ 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: Kernel Trap during installworld caused unrecoverable system
Glen Barber wrote: Hi folks. I was unfortunate enough to encounter a kernel trap in single user mode yesterday when upgrading from 7.1-RC1 to -RC2 using the typical build/install world. I'm still not sure what caused the trap, as the system was rebooting when I saw the screen. As one would expect, this led to an irrecoverable system; the system would automatically drop me into single user mode, as it could only mount the root directory; /bin/sh and /bin/csh would not work (had to use /restore/csh for the minimal digging I actually could do). So, now to the question. Given I could not mount anything other than /, would there have been any way for me to gather debugging information on what caused this failure? (FWIW, I am certain it is not a hardware failure.) You can proceed recovering the system using the tools in /rescue, and once you have shared libraries working again, run savecore to save the crashdump (assuming one was made). Kris ___ 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: Kernel Trap during installworld caused unrecoverable system
On Fri, Dec 26, 2008 at 12:34 PM, Kris Kennaway wrote: > Glen Barber wrote: >> >> Hi folks. >> >> I was unfortunate enough to encounter a kernel trap in single user >> mode yesterday when upgrading from 7.1-RC1 to -RC2 using the typical >> build/install world. >> >> I'm still not sure what caused the trap, as the system was rebooting >> when I saw the screen. As one would expect, this led to an >> irrecoverable system; the system would automatically drop me into >> single user mode, as it could only mount the root directory; /bin/sh >> and /bin/csh would not work (had to use /restore/csh for the minimal >> digging I actually could do). >> >> So, now to the question. Given I could not mount anything other than >> /, would there have been any way for me to gather debugging >> information on what caused this failure? (FWIW, I am certain it is >> not a hardware failure.) > > You can proceed recovering the system using the tools in /rescue, and once > you have shared libraries working again, run savecore to save the crashdump > (assuming one was made). > Hi, Kris. I'll do some digging later today. I appreciate your response. -- Glen Barber ___ 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: amd(8) cores dump when load high
Yes, we found that it crashes when swap is used. On Fri, Dec 26, 2008 at 6:02 PM, Rong-en Fan wrote: > On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric wrote: >> Dear listers, >> >> We currently found that amd frequently cores dump while loading is >> high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to >> 7.1-PRERELEASE. >> >> I have read -stable and svn log of 7-STABLE, but can not found a >> report or a solution. Did anyone have the same issue? Thank you very >> much. >> > > According to my previous experience, amd 6.1.5 crashes > under low memory situations. Not necessary high load. > > Regards, > Rong-En Fan > ___ 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: process stuck in vmopar
2008/12/26 pluknet : > Hi again! > > 2008/12/24 pluknet : >> 2008/12/24 pluknet : >>> 2008/12/24 pluknet : 2008/12/24 pluknet : > Server version: Apache/2.2.11 (Unix) built from sources. > > After issuing kill -9 process stuck in vmopar state forever. > aaa301 2313 0.0 0.0 0 8 ?? DE3:10PM 0:00.01 > /home/aaa301/myb vmopar > > System: FreeBSD 6.2 i386. > One important note. Kernel is built with options QUOTA, and this problem triggered only when this user is overquoted (usage > quota and limit). >>> >>> A bit later various processes begin to stuck in "ufs" state. >> >> backtrace of process that stucks in vmopar: >> >> db> bt 1385 >> Tracing pid 1385 tid 100181 td 0xc6c19960 >> sched_switch(c6c19960,0,1) at sched_switch+0x15b >> mi_switch(1,0) at mi_switch+0x270 >> sleepq_switch(c2954ec8,c0a3d0a0,0,c094c4eb,211,...) at sleepq_switch+0xc1 >> sleepq_wait(c2954ec8,0,c096897c,709,c096897c,...) at sleepq_wait+0x46 >> msleep(c2954ec8,c0ab8e80,244,c0968ca9,0,c9030444,0,c0968eb0,200,c2954ec8,82) >> at >> msleep+0x279 >> vm_page_sleep_if_busy(c2954ec8,1,c0968ca9) at vm_page_sleep_if_busy+0x7c >> vm_object_page_remove(c9030444,4,0,8000,0,0) at vm_object_page_remove+0xf9 >> vnode_pager_setsize(c903c000,4000,0) at vnode_pager_setsize+0xbd >> ffs_write(f734a78c) at ffs_write+0x264 >> VOP_WRITE_APV(c0a09b00,f734a78c) at VOP_WRITE_APV+0x112 >> vnode_pager_generic_putpages(c903c000,f734a8d0,9000,5,f734a860,...) at >> vnode_pag >> er_generic_putpages+0x1ef >> vop_stdputpages(f734a814) at vop_stdputpages+0x1a >> VOP_PUTPAGES_APV(c0a09b00,f734a814) at VOP_PUTPAGES_APV+0x8c >> vnode_pager_putpages(c9030444,f734a8d0,9,5,f734a860) at >> vnode_pager_putpages+0x7 >>e >> vm_pageout_flush(f734a8d0,9,5,0,0,...) at vm_pageout_flush+0x112 >> vm_object_page_collect_flush(c9030444,c29505a8,251,5,4a,...) at >> vm_object_page_c >>ollect_flush+0x2a0 >> vm_object_page_clean(c9030444,0,0,0,0,...) at vm_object_page_clean+0x184 >> vm_object_terminate(c9030444) at vm_object_terminate+0x60 >> vnode_destroy_vobject(c903c000,c6973500,f734aab8,c6c19960,0,...) at >> vnode_destro >>y_vobject+0x39 >> ufs_reclaim(f734aab8) at ufs_reclaim+0x46 >> VOP_RECLAIM_APV(c0a09b00,f734aab8) at VOP_RECLAIM_APV+0x7e >> vgonel(c903c000) at vgonel+0x12d >> vrecycle(c903c000,c6c19960) at vrecycle+0x38 >> ufs_inactive(f734ab40) at ufs_inactive+0x2af >> VOP_INACTIVE_APV(c0a09b00,f734ab40) at VOP_INACTIVE_APV+0x7e >> vinactive(c903c000,c6c19960) at vinactive+0x72 >> vrele(c903c000,c9030444,0,c096897c,1a2,...) at vrele+0x14a >> vm_object_vndeallocate(c9030444) at vm_object_vndeallocate+0xc0 >> vm_object_deallocate(c9030444,c9030444,0,c0968016,8e7) at >> vm_object_deallocate+0 >> xb3 >> vm_map_entry_delete(c722a000,c7194bf4,f734ac20,c081ca37,c722a000,...) >> at vm_map_ >> entry_delete+0x130 >> vm_map_delete(c722a000,0,bfc0) at vm_map_delete+0x18f >> vmspace_exit(c6c19960,c0a4bde0,0,c09463ea,125,...) at vmspace_exit+0xd5 >> exit1(c6c19960,9,2831a4b4,c6c19960,c7234000,...) at exit1+0x496 >> sigexit(c6c19960,9,c7234aa8,0,c09499bc,...) at sigexit+0xdf >> postsig(9) at postsig+0x160 >> ast(f734ad38) at ast+0x35e >> doreti_ast() at doreti_ast+0x17 >> >> db> show alllock >> Process 1385 (httpd) thread 0xc6c19960 (100181) >> exclusive sx user map r = 0 (0xc722a044) locked @ >> /usr/src/sys_uvmem_uip.6.2_RELEASE/vm/vm_map.c:307 >> > > Today I found some interesting details how to reproduce my problem. > > Stucking apache2.x in "vmopar" with subsequent stuck > of other various processes in "ufs" is only triggered with > those options enabled in php.ini: > > extension="xcache.so" > > xcache.size=64M > xcache.count=8 > xcache.slot=64K > xcache.var_size=64M > xcache.var_count=8 > xcache.var_slots=64K > xcache.mmap_path=/tmp/xcache > > Perhaps the problem is related to mmap vs threads interaction. > Any thoughts? > Also seen on 6.3, 6.4 releases. Prepared as PR kern/129956. -- wbr, pluknet ___ 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: process stuck in vmopar
At 03:31 PM 12/26/2008, pluknet wrote: Also seen on 6.3, 6.4 releases. Prepared as PR kern/129956. I wonder if this is the same or similar issue in where the poster is also seeing processes stuck in UFS state http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047118.html ___ 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: -m32 broken on bi-arch amd64 systems?
On Tue, Dec 23, 2008 at 3:54 PM, Peter Wemm wrote: > On Tue, Dec 23, 2008 at 1:07 PM, Garrett Cooper wrote: >> On Dec 23, 2008, at 10:36, Steve Kargl >> wrote: >> >>> On Tue, Dec 23, 2008 at 12:55:04PM -0500, Josh Carroll wrote: > > I also noticed that behavior, shouldn't compiler/linker look > into /usr/lib32 without additional -B switch? > -- > regards, Maciej Suszko. > I don't know if it should or should not, but I can confirm that this behavior was around in 7.0-RELEASE, so it's been that way for quite a while, at least in the 7 branch. >>> >>> Sigh. Read the list archives. It's been this way since Peter >>> Wemm first introduce the ability to run i386 binaries on >>> amd64. >>> >>> -- >>> Steve >> >> Ok, let's bury this topic then. >> Thanks for the confirmation and sorry for the noise. >> -Garrett > > A patch can be extraced from > http://people.freebsd.org/~peter/hammer.diff > that makes it "work", but its not right. It doesn't quite do -I > include overrides right when -m32 is specified. > > It's enough to make just about everything else work. I forgot that I > was building valgrind with it for some time now. I'll give that a shot, provide some feedback, and see if I can *maybe* (shrugs) improve upon it. Thanks Peter! -Garrett ___ 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"
