Re: 7.1-RC2: link_elf: symbol cp_time undefined
On Dec 25, 2008, at 17:36, Jan Henrik Sylvester m...@janh.de wrote: Garrett Cooper wrote: On Dec 25, 2008, at 3:44, Jan Henrik Sylvester m...@janh.de 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 eric...@tamama.org 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 pluk...@gmail.com: 2008/12/24 pluknet pluk...@gmail.com: 2008/12/24 pluknet pluk...@gmail.com: 2008/12/24 pluknet pluk...@gmail.com: 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 m...@janh.de wrote: Garrett Cooper wrote: On Dec 25, 2008, at 3:44, Jan Henrik Sylvester m...@janh.de 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 180
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 ithread_loop, 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 k...@freebsd.org 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 gra...@gmail.com wrote: On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric eric...@tamama.org 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 pluk...@gmail.com: Hi again! 2008/12/24 pluknet pluk...@gmail.com: 2008/12/24 pluknet pluk...@gmail.com: 2008/12/24 pluknet pluk...@gmail.com: 2008/12/24 pluknet pluk...@gmail.com: 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 pe...@wemm.org wrote: On Tue, Dec 23, 2008 at 1:07 PM, Garrett Cooper yanef...@gmail.com wrote: On Dec 23, 2008, at 10:36, Steve Kargl s...@troutmask.apl.washington.edu 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
