CDDA with common programs (ATAng)
Hi all, in the archive I found a discussion about some implementation changes with ATAng which breakes CDDA support for (all?) common programs. Will it ever be possible to use FreeBSD with e.g. kaudiocreator (needs cdparanoia)? I'm no friend of copying audiotracks by hand, give them a more or less apropriate name and feed them into any encoder. There were great tools which could do that automatically but they don't work any more for a reason I cannot follow. Best regards, -Harry pgp0.pgp Description: signature
[current tinderbox] failure on i386/i386
TB --- 2003-11-01 07:42:04 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-01 07:42:04 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-01 07:42:04 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-01 07:43:59 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld 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: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-01 08:45:15 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Nov 1 08:45:15 GMT 2003 Kernel build for GENERIC completed on Sat Nov 1 08:59:48 GMT 2003 TB --- 2003-11-01 08:59:48 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-01 08:59:48 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 1 08:59:48 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/udf/osta.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/umapfs/umap_subr.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/fs/umapfs/umap_vfsops.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter
[current tinderbox] failure on i386/pc98
TB --- 2003-11-01 09:07:51 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-01 09:07:51 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-01 09:07:51 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-01 09:10:23 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld 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: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-01 10:11:43 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Nov 1 10:11:43 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/fb/splash.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/fe/if_fe_cbus.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/kbd/kbd.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/lnc/if_lnc_cbus.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys
Re: NULL td passed to propagate_priority() when using xmms...
It seems Sean Chittenden wrote:
Howdy. I'm not sure if this is a ULE bug or a KSE bug, or both, but,
for those interested (this is using ule 1.67, rebuilding world now),
here's my stack. I couldn't figure out where td was being set to
NULL. :( Oh! Where is TD_SET_LOCK defined? egrep -r didn't turn up
anything. -sc
Its not ULE, I'm running 4BSD and has gotten this on boot for over a
week now, rendering -current totally useless...
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0530569 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0530948 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc06e6bc6 in trap_fatal (frame=0xd675dc2c, eva=0)
at /usr/src/sys/i386/i386/trap.c:820
#4 0xc06e6203 in trap (frame=
{tf_fs = -881065960, tf_es = 16, tf_ds = -881065968, tf_edi = 0, tf_esi =
-871763664, tf_ebp = -696918912, tf_isp = -696918952, tf_ebx = 24, tf_edx = 24,
tf_ecx = -871763664, tf_eax = -879614080, tf_trapno = 12, tf_err = 0, tf_eip =
-1068208110, tf_cs = 8, tf_eflags = 66051, tf_esp = -874093984, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:252
#5 0xc06d6a68 in calltrap () at {standard input}:102
#6 0xc05257ac in propagate_priority (td=0x0)
at /usr/src/sys/kern/kern_mutex.c:152
#7 0xc0525bf9 in _mtx_lock_sleep (m=0xc0796b40, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:635
#8 0xc051a2c4 in ithread_loop (arg=0xcb7a6b00)
at /usr/src/sys/kern/kern_intr.c:539
#9 0xc0518f51 in fork_exit (callout=0xc051a100 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
(kgdb) frame 9
#9 0xc0518f51 in fork_exit (callout=0xc051a100 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
796 callout(arg, frame);
(kgdb) list
791 * cpu_set_fork_handler intercepts this function call to
792 * have this call a non-return function to stay in kernel mode.
793 * initproc has its own fork handler, but it does return.
794 */
795 KASSERT(callout != NULL, (NULL callout in fork_exit));
796 callout(arg, frame);
797
798 /*
799 * Check if a kernel thread misbehaved and returned from its main
800 * function.
(kgdb) frame 8
#8 0xc051a2c4 in ithread_loop (arg=0xcb7a6b00)
at /usr/src/sys/kern/kern_intr.c:539
539 mtx_lock(Giant);
(kgdb) list
534 wakeup(ih);
535 mtx_unlock(ithd-it_lock);
536 goto restart;
537 }
538 if ((ih-ih_flags IH_MPSAFE) == 0)
539 mtx_lock(Giant);
540 ih-ih_handler(ih-ih_argument);
541 if ((ih-ih_flags IH_MPSAFE) == 0)
542 mtx_unlock(Giant);
543 }
(kgdb) frame 7
#7 0xc0525bf9 in _mtx_lock_sleep (m=0xc0796b40, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:635
635 propagate_priority(td);
(kgdb) list
630 * Save who we're blocked on.
631 */
632 td-td_blocked = m;
633 td-td_lockname = m-mtx_object.lo_name;
634 TD_SET_LOCK(td);
635 propagate_priority(td);
636
637 if (LOCK_LOG_TEST(m-mtx_object, opts))
638 CTR3(KTR_LOCK,
639 _mtx_lock_sleep: p %p blocked on [%p] %s, td,
m,
(kgdb) frame 6
#6 0xc05257ac in propagate_priority (td=0x0)
at /usr/src/sys/kern/kern_mutex.c:152
152 sched_prio(td, pri);
(kgdb) list
147 * XXXKSE this gets a lot more complicated under threads
148 * but try anyhow.
149 */
150 if (TD_ON_RUNQ(td)) {
151 MPASS(td-td_blocked == NULL);
152 sched_prio(td, pri);
153 return;
154 }
155 /*
156 * Adjust for any other cases.
---
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0547012
stack pointer = 0x10:0xd6763c6c
frame pointer = 0x10:0xd6763c80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process =
[current tinderbox] failure on ia64/ia64
TB --- 2003-11-01 10:17:16 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-01 10:17:16 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-01 10:17:16 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-01 10:22:22 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld 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: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-01 11:26:40 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Nov 1 11:26:40 GMT 2003 Kernel build for GENERIC completed on Sat Nov 1 11:42:46 GMT 2003 TB --- 2003-11-01 11:42:46 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-01 11:42:46 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 1 11:42:47 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/udf/osta.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/umapfs/umap_subr.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/fs/umapfs/umap_vfsops.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath
buildworld error: rm: tar: is a directory
I'm having problems with current buildworld in gnu now on two different machines in current(today). The latest is the following: rm: tar: is a directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/tar. *** Error code 1 Stop in /usr/src/gnu/usr.bin/tar. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 I'm begining to wonder if I'm getting a complete checkout with cvsup of the gnu tree. Thanks for any suggestions, ed - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-01 11:51:26 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-01 11:51:26 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-01 11:51:26 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-01 11:54:19 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld 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: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-01 12:48:37 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Nov 1 12:48:37 GMT 2003 Kernel build for GENERIC completed on Sat Nov 1 12:57:46 GMT 2003 TB --- 2003-11-01 12:57:46 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-01 12:57:46 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 1 12:57:46 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/udf/osta.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/umapfs/umap_subr.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/umapfs/umap_vfsops.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
Sticky mouse with SCHED_ULE 10-30-03
Are you using moused? Is this SMP or UP? What CPUs are you using? Thanks, Jeff I am having similar problems after my last cvsup (10-31-03) also using a USB MS Intellimouse. Mouse is slow to respond under ULE but fine under 4BSD. The mouse feels like it's being sampled at a slow rate. I am using moused, on a UP Athlon XP 1800+. I am running [EMAIL PROTECTED] at nice 15, but kill the seti process made no notable difference. I failed to check objective performance as the interactive experience was truly difficult to work with and I just wanted to get my work done. =] -Schnoopay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with sysinstall
On Wed, 29 Oct 2003, Doug White wrote: On Wed, 29 Oct 2003, Sergey Matveychuk wrote: Doug White wrote: This is normal and for your protection. you can't edit the disk you're running off of. If you are running off of ad1, make sure 1) you're root when you run sysinstall and b) you aren't mounting any filesystems from ad0. Well, I understand it for slices. But why I can't create new partition in exist slice and newfs it? It was OK in -stable. yes, this is a change to -current. It is for your own safety. My own safety? I can down the system in a million ways, yet can't do what I actually want? A major reason I got fed up with Windows (other than it not working right) was it's insistance of knowing what was best for me. I hope FreeBSD doesn't fall down the same path. Or at least have a kernel option FOOT_SHOOTING, or something, that will disable all the helpful code protection people from themselves. -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with sysinstall
Well, I understand it for slices. But why I can't create new partition in exist slice and newfs it? It was OK in -stable. yes, this is a change to -current. It is for your own safety. My own safety? I can down the system in a million ways, yet can't do what I actually want? A major reason I got fed up with Windows (other than it not working right) was it's insistance of knowing what was best for me. I hope FreeBSD doesn't fall down the same path. Or at least have a kernel option FOOT_SHOOTING, or something, that will disable all the helpful code protection people from themselves. I agree, there should at least be some easy way to turn this behavior off. Maybe a foot.shoot sysctl of some kind. ;-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Show stopper defects for 5.2-RELEASE ++ | Issue | Status| Responsible | Description | |-+-++---| | Panic when | || The panic reported in | | rebuilding | -- | -- | PR kern/58228 must be | | ata-raid arrays | || fixed.| |-+-++---| | | || Performing a | | | || crashdump on an ATA | | ATAng crashdump | | So/ren Schmidt | device can result in | | causes disk | In Progress | Tor Egge | a corrupted MBR | | corruption | || record. Tor has a | | | || possible patch for| | | || this. | |-+-++---| | | || Kris Kennaway reports | | | || that Alpha packages | | pipe/VM | || builds are being | | corruption on | -- | -- | silently corrupted| | Alpha | || and suspects pipe and | | | || vm issues. This must | | | || be investigated and | | | || resolved. | |-+-++---| | | || The panic reported in | | Lingering PSE | || PR kern/58787 is | | instability | -- | -- | likely related to PSE | | | || problems and must be | | | || fixed.| ++ Required features for 5.2-RELEASE ++ | Issue |Status| Responsible | Description | |-+--+---+---| | | | | Kernel and userland | | | | | bits are implemented | | KSE support for | In progress | Jake | but untested and | | sparc64 | | Burkholder| known to be | | | | | incomplete. Required | | | | | for 5.2-RELEASE. | |-+--+---+---| | | | | Userland bits | | KSE support for | | Marcel| implemented, kernel | | alpha | In progress. | Moolenaar | bits not implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+--+---+---| | | | | Significant parts of | | | | | the network stack | | | | | (especially IPv4 and | | | | | IPv6) now have| | | | | fine-grained locking | | | | | of their data | | | | | structures. However, | | | | | it is not yet | | | | | possible for the | | | | | netisr threads to run | | Fine-grained| | | without Giant, due to | | network stack | | | dependencies on | | locking
Re: problems with sysinstall
Wed, Oct 29, 2003 at 17:32:29, dwhite (Doug White) wrote about Re: problems with sysinstall: Well, I understand it for slices. But why I can't create new partition in exist slice and newfs it? It was OK in -stable. DW yes, this is a change to -current. It is for your own safety. Don't protect me when I didn't ask for it. FYI, phk@ said here some time ago how to remove this protection, and said that this nursery protection is in effect only until someone implements better algorithm. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with sysinstall
Wed, Oct 29, 2003 at 05:44:44, sem (Sergey Matveychuk) wrote about problems with sysinstall: SM The first one: when I install -current on disk where WinXP on first SM slice, sysinstall brakes WinXP boot complete. I got 'Missing operation SM system' everytime. Even I've tried 'fixboot' and reinstall WinXP. SM Helps only 'dd if=/dev/zero of=/dev/ad0 count=100' and reinstall WinXP SM on clean disk. It can be better reported if you show here 1) 0th block of disk (where MBR and master PT resides) 2) full PT listing, with both standard fdisk and linux fdisk (from ports) and both of them before installing FreeBSD (when XP works) and after (when is already broken). SM When I've installed first -current on first slice and second -current on SM second slice I got booting only first one. I use grub and either I set SM root(hd1,0) or root(hd1,1) (yes, it's a second disk) and 'chainloader SM +1' and 'boot' I've got always first -current boot. Looks like problem SM with boot sector where hardcoded booting from first slice (?). Yes, this is tied to algorithm of boot1. On first step, it founds first *active* BSD partition in master PT. If didn't find any, it tries to find BSD partition in any state (inactive, due to first step failure). When found, records its number and starts boot2. Boot switcher, called boot0 (/boot/boot0) or BootEasy (in sysinstall), changes active partition flag (see boot0cfg(8)). When you use GRUB to call chainloader, it will start boot1 with the described result. To select boots using GRUB, use UFS1 (GRUB can't understand UFS2), with root (hd0,1); boot /boot/loader, or use boot0. SM The second: when I've tried to save results from Fdisk or Label menu SM I've got the message: 'ERROR: Unable to write data to disk ad0!' SM Why? I can change slices and partitions only when I boot from CD-ROM. Current GEOM implementation is too restrictive and doesn't allow any write to disk which has opened slices/partitions. phk@ promised change of this as soon as someone gives working implementation. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDDA with common programs (ATAng)
On Saturday 01 November 2003 09:08, Harald Schmalzbauer wrote: Hi all, in the archive I found a discussion about some implementation changes with ATAng which breakes CDDA support for (all?) common programs. Will it ever be possible to use FreeBSD with e.g. kaudiocreator (needs cdparanoia)? I'm no friend of copying audiotracks by hand, give them a more or less apropriate name and feed them into any encoder. There were great tools which could do that automatically but they don't work any more for a reason I cannot follow. There's a patch for cdparanoia that is floating around that fixes this, created by Vladimir Kushnir. I'm not sure if a PR was sent for this, if not, I'll create one (but I'm not sure cdparanoia still works on -STABLE with this patch). Anyways, you can find the patch here: http://www.piwebs.com/freebsd/atang/patch-interface__cooked_interface.c.1 Just place it in the files/ directory of the cdparanoia port. Best regards, Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CDDA with common programs (ATAng)
On Saturday 01 November 2003 16:54, Arjan van Leeuwen wrote: On Saturday 01 November 2003 09:08, Harald Schmalzbauer wrote: Hi all, in the archive I found a discussion about some implementation changes with ATAng which breakes CDDA support for (all?) common programs. Will it ever be possible to use FreeBSD with e.g. kaudiocreator (needs cdparanoia)? I'm no friend of copying audiotracks by hand, give them a more or less apropriate name and feed them into any encoder. There were great tools which could do that automatically but they don't work any more for a reason I cannot follow. There's a patch for cdparanoia that is floating around that fixes this, created by Vladimir Kushnir. I'm not sure if a PR was sent for this, if not, I'll create one (but I'm not sure cdparanoia still works on -STABLE with this patch). Anyways, you can find the patch here: http://www.piwebs.com/freebsd/atang/patch-interface__cooked_interface.c.1 Just place it in the files/ directory of the cdparanoia port. Sorry, scrap that last sentence. You have to apply this patch _after_ doing 'make patch' for the port. Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Jail Hosting required
Hi Please can someone recommend a hosting service in the UK that can provide a Jail service for us. Please reply off list. Regards ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
if_xname, byte order and OpenBSD 3.4 + CARP
Hello, this just a short yes, we are aware of things message. As OpenBSD 3.4 was released three days ago, we will release pf 2.0 soon. However, before that can take place there are some issues that have to be resolved beforehand: 1) As you may know, Brooks Davis has finally brought if_xname to struct ifnet (which actually reduces the diff count between Free- and OpenBSD). To make out pf build with 501113 again, we have to change somethings never the less. 2) Mark Bojara reported byte order related problems to the pf mailing list some time ago, which lead to discoverage of several problems in that general area. We think we found everything by now, but will need some testing. 3) Do you have anything unresolved? Now is the time to report! Thank you for your patience and support! I CC to [EMAIL PROTECTED] as security/pf is broken after 501113 as well. This will be fixed with a bump to version 2.0 as soon as we release. P.S.: I am working on a port of the CARP (Common Address Redundancy Protocol), which is about to become useable. I will put a patchset on the webpage, for those interested. -- Best regards, Max mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall's fdisk/disklabel should be improved
Sun, Oct 26, 2003 at 18:58:52, q (Ulrich Spoerlein) wrote about Sysinstall's fdisk/disklabel should be improved: US First of all, the Partition Editor has the 'A' option to use all of the US available HDD space. It creates a DOS-compatible slice (starting at US sector 63 and ending on cylinder boundary). This is completely useless US on servers No, even on servers one may use only 6 data partitions or less, as to fit in one bsdlabel. US and the help menu says that sysinstall will ask if it should US create a DOS-compatible slice or not. However no such question is ever US asked. I think help page should be fixed, but not fdisk code. US Creating the slice manually, specifying the complete disk as 'size' will US also leave the start and end of the disk unpartitioned (again, no US question is ever asked). First track is leaved for compatibility with DOS-styled scheme. It is required for many BIOSes which want to determine provided geometry by reading PT. Some last part which can't fit in cylinder in declared geometry, rest unused. It is feature of DOS compatibility mode and there is no need to warn it. US Ok, then the solution would be to drop to a shell and run fdisk by hand. US However there is no fdisk/disklabel/newfs in that shell. Even 'ls' is US not found. Running the LiveCD will give you a working fdisk/disklabel US but the man-pages are not useable (manpath.config can't be found). US Succeding in sliceing/partitioning without man-pages will still require US to reboot sysinstall, because it doesn't re-read the partition/slice US table but uses the in-memory table instead (I didn't find an option to US re-read this information from disk) Does you say for 4.x or 5.x? Behavior you said is for 4.x. US Please consider this, right now sysinstall is a tool which can only be US used if you know all of it's bugs. IMHO even the OpenBSD installer is US sometimes more elegant than sysinstall. US Really brave souls should take a look at this list: US http://www.freebsd.org/cgi/query-pr-summary.cgi?text=sysinstall sysinstall is ugly, but all you said for it doesn't matter, IMHO. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall's fdisk/disklabel should be improved
Wed, Oct 29, 2003 at 16:43:12, q (Ulrich Spoerlein) wrote about Re: Sysinstall's fdisk/disklabel should be improved: It is NOT useless. Why do you think it is? Perhaps you don't relize that some BIOS's wont boot from a hard disk that isn't partitioned to agree with the specifications of the PeeCee. If you want to treat your PC as a Sun, don't -- buy a Sun, FreeBSD runs on that too. US What exactly do you mean by PC Specification? I'm not trying to make a US dangerously dedicated disk. I just don't need a spare 63 sectors for US DOS-compatibility. And leaving the first 63 sectors untouched is a US DOS-ism, not a PC-ism. Well, dangerously dedicated is name of partitioning mode which doesn't leave one track for dos PT and MBR switcher. It's just name. If you doesn't like this name, rename it in your mind. US The BIOS' only job is to load the MBR (sector 0) which will then read US and check the partition table and load the first sector of the 'active' US partition into memory and pass execution to it. In real, BIOS can read master PT and even BPB on FAT to found which geometry (normal/ECHS/LBA-assist) should be reported. US Therefore I created a big partition from sector 1 to the last sector US with fdisk from the LiveCD. After writing the partition table I had to US reboot sysinstall because it didn't recognise the partition layout has US changed. So could someone be so kind to teach sysinstall a 'reset' US button which will re-read the partition table and the disklabel info? It should be done automatically unless there are opened/mounted partitions on this disk. If you don't see changes, check whether you really asked to write changes immediately. Otherwise, they are delayed until commit phase. US PS: I have a Sparcstation 20 and a b0rken Ultra1. None of them run FreeBSD. Do you consider this as a bug? -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-11-01 17:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-01 17:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-01 17:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-01 17:02:33 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld 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: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-01 18:06:12 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Nov 1 18:06:12 GMT 2003 Kernel build for GENERIC completed on Sat Nov 1 18:18:10 GMT 2003 TB --- 2003-11-01 18:18:10 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-01 18:18:10 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 1 18:18:10 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/fs/udf/osta.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/fs/umapfs/umap_subr.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/fs/umapfs/umap_vfsops.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm
Re: buildworld error: rm: tar: is a directory
On Sat, Nov 01, 2003 at 04:48:42AM -0800, [EMAIL PROTECTED] wrote: I'm having problems with current buildworld in gnu now on two different machines in current(today). The latest is the following: rm: tar: is a directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/tar. *** Error code 1 Stop in /usr/src/gnu/usr.bin/tar. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 I'm begining to wonder if I'm getting a complete checkout with cvsup of the gnu tree. ``rm -rf /usr/obj/usr/src/gnu/usr.bin/tar'' and try again. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
ACPI S1/S3 power states not working
Hi, I'm using a Dell Inspiron 8000 running BIOS A22 (latest AFAIK) and FreeBSD 5.1-RELEASE. I've compiled a fixed DSDT following Stijn's instructions which did fix a bunch of errors during/after bootup. I'm trying to get some of the power saving states working but am having no luck and can't seem to find any solution in the mailing lists. When I try switch to power state S1 or S3 I get the following kernel message: panic: resource_list_release: couldn't find resource After which the kernel fails to flush open buffers and reboots 15 seconds later. At no point does the screen go blank. I've tried setting hw.acpi.sleep_delay to 5 as well. No luck. Has anyone had success with an Inspiron 8000? Would greatly appreciate any help. Thanks, Aragon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI S1/S3 power states not working
I'm using Motherboard based on VIA chipset and the S3 doesnt work correctly. On resume if there are X the system doesn't restart and without X the system resmumes but hangs few later. I'm using FreeBSD 5.1-CURRENT: Wed Oct 29 15:35:15 CET 2003 i386 On Sat, 1 Nov 2003 22:02:56 +0200 Aragon Gouveia [EMAIL PROTECTED] wrote: Hi, I'm using a Dell Inspiron 8000 running BIOS A22 (latest AFAIK) and FreeBSD 5.1-RELEASE. I've compiled a fixed DSDT following Stijn's instructions which did fix a bunch of errors during/after bootup. I'm trying to get some of the power saving states working but am having no luck and can't seem to find any solution in the mailing lists. When I try switch to power state S1 or S3 I get the following kernel message: panic: resource_list_release: couldn't find resource After which the kernel fails to flush open buffers and reboots 15 seconds later. At no point does the screen go blank. I've tried setting hw.acpi.sleep_delay to 5 as well. No luck. Has anyone had success with an Inspiron 8000? Would greatly appreciate any help. Thanks, Aragon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld error: rm: tar: is a directory
Mensaje citado por Ruslan Ermilov [EMAIL PROTECTED]: | On Sat, Nov 01, 2003 at 04:48:42AM -0800, [EMAIL PROTECTED] wrote: | I'm having problems with current buildworld in gnu now on two different | machines in current(today). The latest is the following: | | rm: tar: is a directory | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin/tar. | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin/tar. | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin. | *** Error code 1 | | I'm begining to wonder if I'm getting a complete checkout with cvsup | of the gnu tree. | | ``rm -rf /usr/obj/usr/src/gnu/usr.bin/tar'' and try again. Ruslan That didn't seem to work. I've erased the /usr/obj/usr tree several times and even gnu but without luck. After resuping getting the error doing a rm -rf /usr/obj/usr/src/gnu/usr.bin/tar and then another make buildworld, I continue to get: === gnu/usr.bin/tar rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o exclude.o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o hash.o human.o mktime.o modechange.o prepargs.o print-copyr.o quotearg.o safe-read.o save-cwd.o savedir.o unicodeio.o xgetcwd.o xmalloc.o xstrdup.o xstrtoul.o xstrtoumax.o buffer.o compare.o create.o delete.o extract.o incremen.o list.o mangle.o misc.o names.o rtapelib.o tar.o update.o tar.1.gz tar.1.cat.gz rm: tar: is a directory *** Error code 1 I've actually got two different machines doing the same thing. At least I'm consistent :-( Thanks for your help, ed - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld error: rm: tar: is a directory
eculp writes: Mensaje citado por Ruslan Ermilov [EMAIL PROTECTED]: | On Sat, Nov 01, 2003 at 04:48:42AM -0800, [EMAIL PROTECTED] wrote: | I'm having problems with current buildworld in gnu now on two different | machines in current(today). The latest is the following: | | rm: tar: is a directory | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin/tar. | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin/tar. | *** Error code 1 | | Stop in /usr/src/gnu/usr.bin. | *** Error code 1 | | I'm begining to wonder if I'm getting a complete checkout with cvsup | of the gnu tree. | | ``rm -rf /usr/obj/usr/src/gnu/usr.bin/tar'' and try again. Ruslan That didn't seem to work. I've erased the /usr/obj/usr tree several times and even gnu but without luck. After resuping getting the error doing a rm -rf /usr/obj/usr/src/gnu/usr.bin/tar and then another make buildworld, I continue to get: Try 'cvs update -PdA' Jean-Marc -- Jean-Marc Zucconi -- PGP Key: finger [EMAIL PROTECTED] [KeyID: 400B38E9] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld error: rm: tar: is a directory
cvs update -PAd Pruning is very important. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Fri, 31 Oct 2003, Michal Mertl wrote: ... As I recall, when I used a crossover cable, I could not get the adapters to go to 1000, only 100. That might have been the cable, or not. I can confirm it works equally well with crossover as with straight cable. Depends usually. Some cards have auto-crossover detection now. And so do some switches (ex. Catalyst 3700 series). -- Michal Mertl Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ata and mfs problems
On my Fujitsu-Siemens S-4572 I get random hangs when doing recursive copying to af mfs device. I suspect it has something to do with the fact the I still get a lot of spurious interrupst on the ata controller. I'm doing the following: dd if=/dev/zero of=mfsroot bs=1k count=25000 mdconfig -a -t vnode -f mfsroot -u0 disklabel -r -w md0 auto newfs /dev/md0c mkdir -p /mnt/mfs mount /dev/md0 /mnt/mfs cp -R /some/dir /mnt/mfs The laptop will keep working for a while and the things will start to hang. If I try to reboot it will only hang more. I'm unable to get into the debugger - all I get to see is: ata1: spurious interrupt - status = 0xff error = 0xff Only thing I can do is turn it off :( Attached is the verbose dmesg. Sven Esbjerg -- http://www.usenet.dk/netikette - på forhånd tak. Copyright (c) 1992-2003 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 5.1-CURRENT #5: Sat Nov 1 17:31:41 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BLADE Preloaded elf kernel /boot/kernel/kernel at 0xc0881000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0881244. Calibrating clock(s) ... i8254 clock: 1193136 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 746339075 Hz CPU: Intel Pentium III (746.34-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268435456 (256 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c26000 - 0x0fb41fff, 250724352 bytes (61212 pages) 0x0fff2000 - 0x0fff7fff, 24576 bytes (6 pages) avail memory = 251039744 (239 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6380 bios32: Entry = 0xfd8b0 (c00fd8b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd8b0+0x11e pnpbios: Found PnP BIOS data at 0xc00f63d0 pnpbios: Entry = f:908b Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: 802.11 Link Layer null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: FUJTHYMEon motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=71948086) pcibios: BIOS version 2.10 Using $PIR table, 5 entries at 0xc00fdf70 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded00B 0x61 3 4 5 7 9 10 11 14 embedded07D 0x63 3 4 5 7 10 11 14 15 embedded0 20A 0x62 3 4 5 7 9 10 11 14 embedded0 19A 0x60 3 4 5 7 9 10 11 14 embedded0 19B 0x61 3 4 5 7 9 10 11 14 embedded0 18A 0x62 3 4 5 7 9 10 11 14 embedded0 18B 0x63 3 4 5 7 9 10 11 14 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 19 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 19 func 1 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_timer0: 24-bit timer at 3.579545MHz port 0xff08-0xff0b on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_cpu0: CPU port 0x530-0x537 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.EIO_.LNKB irq 9: [ 3 4 5 7 9 10 11] low,level,sharable 0.0.1 \\_SB_.PCI0.EIO_.LNKD irq 15: [ 3 4 5 7 10 11 15] low,level,sharable 0.7.3 \\_SB_.PCI0.EIO_.LNKC irq 9: [ 3 4 5 7 9 10 11] low,level,sharable 0.20.0 \\_SB_.PCI0.EIO_.LNKA irq 9: [ 3 4 5 7 9 10 11] low,level,sharable 0.19.0 \\_SB_.PCI0.EIO_.LNKB irq 9: [ 3 4 5 7 9 10 11] low,level,sharable 0.19.1 \\_SB_.PCI0.EIO_.LNKC irq 9: [ 3 4 5 7 9 10 11] low,level,sharable 0.18.0 \\_SB_.PCI0.EIO_.LNKD irq 15: [ 3 4 5 7 10 11 15] low,level,sharable 0.18.1 before setting
Re: buildworld error: rm: tar: is a directory
Mensaje citado por Jean-Marc Zucconi [EMAIL PROTECTED]: | eculp writes: | | Mensaje citado por Ruslan Ermilov [EMAIL PROTECTED]: | | On Sat, Nov 01, 2003 at 04:48:42AM -0800, [EMAIL PROTECTED] wrote: | | I'm having problems with current buildworld in gnu now on two | different | | machines in current(today). The latest is the following: | | | | rm: tar: is a directory | | *** Error code 1 | | | | Stop in /usr/src/gnu/usr.bin/tar. | | *** Error code 1 | | | | Stop in /usr/src/gnu/usr.bin/tar. | | *** Error code 1 | | | | Stop in /usr/src/gnu/usr.bin. | | *** Error code 1 | | | | I'm begining to wonder if I'm getting a complete checkout with cvsup | | of the gnu tree. | | | | ``rm -rf /usr/obj/usr/src/gnu/usr.bin/tar'' and try again. | | Ruslan | | That didn't seem to work. I've erased the /usr/obj/usr tree several | times and even gnu but without luck. After resuping getting the | error doing a rm -rf /usr/obj/usr/src/gnu/usr.bin/tar and then | another make buildworld, I continue to get: | | Try 'cvs update -PdA' | Jean-Marc, I haven't tried it yet but I think that is the problem. I just found a /usr/src/gnu/usr.bin/tar/tar/attic that I suspect as causing problem and that I'm assuming that the -P would take care of. I'm trying yet another make buildworld and it seems to have passed the problem but I am not declaring victory yet :-) but I feel that this or the -PdA will solve the problem. Thanks for the suggestion, ed - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata and mfs problems
It seems Sven Esbjerg wrote: On my Fujitsu-Siemens S-4572 I get random hangs when doing recursive copying to af mfs device. I suspect it has something to do with the fact the I still get a lot of spurious interrupst on the ata controller. Those spurious interrupts are because ata1 share irq15 with USB. Most HW was not designed for this. If its a problem that they get printed dont bot verbose or comment out the prints in ata-lowlevel.c There is a problem in the kernel that makes the console lockup if there is too much printed too fast from inside the kernel.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
Barney Wolff wrote: Implies the sending host is not honoring the MTU restriction when deciding whether or not to frag packets. 67582 looks awfully bogus even as a pre-frag length. How could that come over the wire? The sending host is not honoring the MTU restriction? 8-) 8-). Most likely, a direct call to ether_output, or a code path that results in fragmentation not being implemented; see my other post: it could be that he's using NFS over UDP, and that's doing it. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld error: rm: tar: is a directory
Mensaje citado por M. Warner Losh [EMAIL PROTECTED]: | cvs update -PAd | | Pruning is very important. Warner, It hadn't even dawned on me but, after several days of suffering with this problem, I couldn't agree more. I am converted, believe me. I will be doing that more often. I've become too entrenched with cvsup, I'm afraid. Thanks very much, ed - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD-CURRENT kernel hangs on starting KDE
Hi, Some months ago I installed a FreeBSD-current system on my desktop computer. I use the KDE desktop environment and I compiled really everything from ports. I periodically maintain it so my system is up-to-date. I have been experiencing a problem with FreeBSD-current kernel all the time. Some months ago I tried to compile a custom kernel based on GENERIC commenting out the not necessary hardwares from my config, like RAID and most of NICs, etc. (I think it is a general thing when customizing). Although I haven't tested it too much the kernel booted properly and everything worked good in console. Trying to start KDE caused system crash (I guess in kernel level). I have spent long days to find the reason trying almost all combination of kernel config settings without luck. Ok, but GENERIC is worked with some custom lines added to it (but I couldn't remove anything except debugging). Since 25th of September something changed in the current kernel source tree because I am not able to compile any kernel, even GENERIC, with which KDE would start without freezing the whole machine partly or completely. Unfortunately I did not preserve any earlier source tree version, I just upgraded it with cvsup before the compilations. Now I use a newer base system than the kernel, which results in an unstable operation (it is normal I guess), because I only preserved the lastest goog-working /boot/kernel binaries I compiled before. KDE freezing in detail -- System: FreeBSD 5.1-CURRENT i386 Relevant hardware config: Mainboard : ASUS P4S533-E (SIS645DX north, SIS962/L south bridges) Memory : PC2700 512MB DDR RAM (memtest86 tested) VGA card : ATI RADEON 9000 PRO Very recent FreeBSD-current GENERIC kernel (was compiled exaclty as described in the handbook) completely freezes some seconds later after starting KDE. Input peripherials/ACPI button become unusable and the machine does not respond to ICMP on LAN so it completely hangs. It is not thought a hardware failure because earlier kernel with the same config (synced with cvsup on 25th Sept. 2003) works very good. KDE and XFree86 were compiled from the lastest ports so they are up-to-date. Logs does not show any usable information related to this freezing so I think there is no point to attach any of them here (XFree86 just stops logging before some radeondrm messages would be logged in normal case). I guess so it is closely an ATI-driver related problem because when I tested the same base system/kernel with an S3Trio VGA card that worked and the ATI did not. This ATI is a common card (with dual head+tv output) and not a cheap one at all (I currently use it on other OS-es on the same machine without experiencing any problems). Since I have been experiencing these problems I sync my source tree more times a week and I'm trying to compile a working kernel without luck. Note: If I switch back to console immediately after X server started and before KDE begins to initialize then KDE starts up properly. When I go back to X again I see the desktop as everything would be right. Some seconds later the same freezing takes place. First the keyboard blocks, then the mouse starts clogging and the whole machine totally hangs. I would appreciate any help in connection with this problem's solution. Thanks in advance, Tams R. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD-CURRENT kernel hangs on starting KDE
I'm sorry for my previous e-mail, I hope it will look better :) Some months ago I installed a FreeBSD-current system on my desktop computer. I use the KDE desktop environment and I compiled really everything from ports. I periodically maintain it so my system is up-to-date. I have been experiencing a problem with FreeBSD-current kernel all the time. Some months ago I tried to compile a custom kernel based on GENERIC commenting out the not necessary hardwares from my config, like RAID and most of NICs, etc. (I think it is a general thing when customizing). Although I haven't tested it too much the kernel booted properly and everything worked good in console. Trying to start KDE caused system crash (I guess in kernel level). I have spent long days to find the reason trying almost all combination of kernel config settings without luck. Ok, but GENERIC is worked with some custom lines added to it (but I couldn't remove anything except debugging). Since 25th of September something changed in the current kernel source tree because I am not able to compile any kernel, even GENERIC, with which KDE would start without freezing the whole machine partly or completely. Unfortunately I did not preserve any earlier source tree version, I just upgraded it with cvsup before the compilations. Now I use a newer base system than the kernel, which results in an unstable operation (it is normal I guess), because I only preserved the lastest goog-working /boot/kernel binaries I compiled before. KDE freezing in detail -- System: FreeBSD 5.1-CURRENT i386 Relevant hardware config: Mainboard : ASUS P4S533-E (SIS645DX north, SIS962/L south bridges) Memory : PC2700 512MB DDR RAM (memtest86 tested) VGA card : ATI RADEON 9000 PRO Very recent FreeBSD-current GENERIC kernel (was compiled exaclty as described in the handbook) completely freezes some seconds later after starting KDE. Input peripherials/ACPI button become unusable and the machine does not respond to ICMP on LAN so it completely hangs. It is not thought a hardware failure because earlier kernel with the same config (synced with cvsup on 25th Sept. 2003) works very good. KDE and XFree86 were compiled from the lastest ports so they are up-to-date. Logs does not show any usable information related to this freezing so I think there is no point to attach any of them here (XFree86 just stops logging before some radeondrm messages would be logged in normal case). I guess so it is closely an ATI-driver related problem because when I tested the same base system/kernel with an S3Trio VGA card that worked and the ATI did not. This ATI is a common card (with dual head+tv output) and not a cheap one at all (I currently use it on other OS-es on the same machine without experiencing any problems). Since I have been experiencing these problems I sync my source tree more times a week and I'm trying to compile a working kernel without luck. Note: If I switch back to console immediately after X server started and before KDE begins to initialize then KDE starts up properly. When I go back to X again I see the desktop as everything would be right. Some seconds later the same freezing takes place. First the keyboard blocks, then the mouse starts clogging and the whole machine totally hangs. I would appreciate any help in connection with this problem's solution. Thanks in advance, Tamás R. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-11-01 21:03:26 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-01 21:03:26 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-01 21:03:26 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-01 21:05:28 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld 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: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-11-01 22:02:58 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Nov 1 22:02:58 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/fb/splash.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/fe/if_fe_cbus.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/kbd/kbd.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/lnc/if_lnc_cbus.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys
Re: FreeBSD-CURRENT kernel hangs on starting KDE
System: FreeBSD 5.1-CURRENT i386 Relevant hardware config: Mainboard : ASUS P4S533-E (SIS645DX north, SIS962/L south bridges) Memory : PC2700 512MB DDR RAM (memtest86 tested) VGA card : ATI RADEON 9000 PRO I had similar lockups with a SuperMicro P6DGH (dual PIII/850)/ATI All-in Wonder (RADEON 7200)/Intel Pro100+ which were solved by moving the Ethernet card to another IRQ (it was configured to share 11 by default, moved it to 9). The system would just stop working - mouse frozen, no keyboard response, etc. I use KDE, also. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Sat, Nov 01, 2003 at 01:09:07PM -0800, Terry Lambert wrote: Barney Wolff wrote: Implies the sending host is not honoring the MTU restriction when deciding whether or not to frag packets. 67582 looks awfully bogus even as a pre-frag length. How could that come over the wire? The sending host is not honoring the MTU restriction? 8-) 8-). Most likely, a direct call to ether_output, or a code path that results in fragmentation not being implemented; see my other post: it could be that he's using NFS over UDP, and that's doing it. Er, how is it possible to send a UDP packet 65535? Last time I looked it was a 16-bit field. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic during shutdown in lockmgr()
Hi, with a -CURRENT kernel built today I am consistently getting a panic during shutdown. Unfortunately a debug kernel refuses to do a core dump, so I only have a naked stack trace: panic: lockmgr: thread 0xc1918720, not exclusive lock holder 0xc06b5660 unlocking #0 0xc04fc40a in doadump () #1 0xc04fcaac in boot () #2 0xc04fce03 in poweroff_wait () #3 0xc04eff3c in lockmgr () #4 0xc054b2b2 in vop_stdunlock () #5 0xc054b15a in vop_defaultop () #6 0xc05e2f73 in ufs_vnoperate () #7 0xc0555cd8 in vput () #8 0xc05d3a86 in ffs_sync () #9 0xc0558a5d in sync () #10 0xc04fc5a4 in boot () #11 0xc04fc1bf in reboot () #12 0xc0632372 in syscall () #13 0xc0622fdd in Xint0x80_syscall () This panic occurs when I shut the machine down with all filesystems mounted. I can avoid it when I go to single user mode and umount all filesystems first. Please let me know if I can provide further information. Regards -Thorsten -- The moon may be smaller than Earth, but it's further away. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld error: rm: tar: is a directory
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : Mensaje citado por M. Warner Losh [EMAIL PROTECTED]: : : | cvs update -PAd : | : | Pruning is very important. : : Warner, : : It hadn't even dawned on me but, after several days of suffering with this : problem, I couldn't agree more. I am converted, believe me. I will be doing : that more often. I've become too entrenched with cvsup, I'm afraid. cvs and cvsup operate slightly differently. And this is the biggest gotcha... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
lockmgr panic on shutdown
I can confirm the lockmgr panic on shutdown reported by someone else earlier (whose message I mistakenly deleted). It looks like swapper is trying to undo a lock from pagedaemon and runs into trouble. This is probably related to the Giant pushdown of vm_pageout() that alc did last week. I'm building with INVARIANTS to see if that will catch more info. Will report back soon. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pthread_mutex_lock crashed
Hello! I've tested MICO port (CORBA implementation) both on -stable and -current. I use lang/gcc33 port for -stable. On -stable all goes right, but on -current one example crashed in pthread_mutex_lock(). Here is gdb back tracing: #0 0x280830c9 in _atomic_lock () from /usr/lib/libc_r.so.5 #1 0x28083094 in _spinlock_debug () from /usr/lib/libc_r.so.5 #2 0x28088962 in _pthread_mutex_trylock () from /usr/lib/libc_r.so.5 #3 0x28088d12 in pthread_mutex_lock () from /usr/lib/libc_r.so.5 #4 0x282d5fcb in CORBA::ServerlessObject::_deref() () from /usr/local/lib/libmico2.3.11.so #5 0x282ceac6 in ObjVarCORBA::ContextList::release(CORBA::ContextList*) () from /usr/local/lib/libmico2.3.11.so ... etc. The port has been built with -lc_r on -current. Can you comment it? --- Sem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lockmgr panic on shutdown
More info.
I think this is actually related to kan's reversion of
src/sys/kern/vfs_default.c. I'm trying rev 1.88 of that file.
In the meantime, here is the panic message and backtrace. I have a
crashdump if desired.
panic: lockmgr: thread 0xc493be40, not exclusive lock holder 0xc071f320 unlocking
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0510884 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0510be7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc05043ea in lockmgr (lkp=0xc49af428, flags=6, interlkp=0x140,
td=0xc493be40) at /usr/src/sys/kern/kern_lock.c:414
#4 0xc055e91f in vop_stdunlock (ap=0x0) at /usr/src/sys/kern/vfs_default.c:299
#5 0xc055e768 in vop_defaultop (ap=0x0) at /usr/src/sys/kern/vfs_default.c:161
#6 0xc061ed88 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2793
#7 0xc06173d0 in ufs_inactive (ap=0x0) at vnode_if.h:1044
#8 0xc061ed88 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2793
#9 0xc05686d7 in vput (vp=0xc49af36c) at vnode_if.h:953
#10 0xc0610245 in ffs_sync (mp=0xc47b2800, waitfor=2, cred=0xc1d07e80,
td=0xc071f320) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1169
#11 0xc056ade4 in sync (td=0xc071f320, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:142
#12 0xc05103e0 in boot (howto=8) at /usr/src/sys/kern/kern_shutdown.c:281
#13 0xc0510046 in reboot (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_shutdown.c:178
#14 0xc066cf32 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 0, tf_ebp =
-1077937104, tf_isp = -574005900, tf_ebx = 2, tf_edx = -1, tf_ecx = 3, tf_eax = 55,
tf_trapno = 12, tf_err = 2, tf_eip = 134516011, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077937172, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1012
#15 0xc065d91d in Xint0x80_syscall () at {standard input}:144
On Sat, 1 Nov 2003, Doug White wrote:
I can confirm the lockmgr panic on shutdown reported by someone else
earlier (whose message I mistakenly deleted).
It looks like swapper is trying to undo a lock from pagedaemon and runs
into trouble. This is probably related to the Giant pushdown of
vm_pageout() that alc did last week.
I'm building with INVARIANTS to see if that will catch more info. Will
report back soon.
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: lockmgr panic on shutdown
I can confirm the lockmgr panic on shutdown reported by someone else
earlier (whose message I mistakenly deleted).
It looks like swapper is trying to undo a lock from pagedaemon and runs
into trouble. This is probably related to the Giant pushdown of
vm_pageout() that alc did last week.
I'm building with INVARIANTS to see if that will catch more info. Will
report back soon.
Just happened me too. I think I see the problem:
When boot() calls sync(), it passes thread0 as the thread argument.
This gets propgated up to ffs_sync, which:
calls vget(), which takes a thread argument.
does some stuff
calls vput(), which does _not_ take a thread argument
The vget() is passed thread0, as passed from boot.
The vput() gets the current thread, which is the process calling boot.
The unlocking in vput is asserting that the same thread that aquired
the lock is releasing it, which seems reasonable.
The obvious solution might be to change line 1161 of ffs_vfsops to
pass vget() curthread rather than td. I assume there's a good
reason why thread0 is passed from boot(), but I can't see why
that's of any use to the vnode locking.
i.e.:
Index: ffs_vfsops.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.221
diff -u -r1.221 ffs_vfsops.c
--- ffs_vfsops.c1 Nov 2003 05:51:54 - 1.221
+++ ffs_vfsops.c2 Nov 2003 03:06:42 -
@@ -1158,7 +1158,7 @@
continue;
}
mtx_unlock(mntvnode_mtx);
- if ((error = vget(vp, lockreq, td)) != 0) {
+ if ((error = vget(vp, lockreq, curthread)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;
How come tha parameters to vget and vput are lopsided like this?
This might have something to do with the commit
of revision 1.218 of ffs_vfsops.c, but I'm not sure.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: lockmgr panic on shutdown
For giggles I'm rolling back vfs_default.c back to 1.87 since its along
the backtrace path.
I suspect I'll need to back up the whole thing to before the commit for
the struct mount locking until jeff kan can straighten things out.
On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote:
I can confirm the lockmgr panic on shutdown reported by someone else
earlier (whose message I mistakenly deleted).
It looks like swapper is trying to undo a lock from pagedaemon and runs
into trouble. This is probably related to the Giant pushdown of
vm_pageout() that alc did last week.
I'm building with INVARIANTS to see if that will catch more info. Will
report back soon.
Just happened me too. I think I see the problem:
When boot() calls sync(), it passes thread0 as the thread argument.
This gets propgated up to ffs_sync, which:
calls vget(), which takes a thread argument.
does some stuff
calls vput(), which does _not_ take a thread argument
The vget() is passed thread0, as passed from boot.
The vput() gets the current thread, which is the process calling boot.
The unlocking in vput is asserting that the same thread that aquired
the lock is releasing it, which seems reasonable.
The obvious solution might be to change line 1161 of ffs_vfsops to
pass vget() curthread rather than td. I assume there's a good
reason why thread0 is passed from boot(), but I can't see why
that's of any use to the vnode locking.
i.e.:
Index: ffs_vfsops.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.221
diff -u -r1.221 ffs_vfsops.c
--- ffs_vfsops.c1 Nov 2003 05:51:54 - 1.221
+++ ffs_vfsops.c2 Nov 2003 03:06:42 -
@@ -1158,7 +1158,7 @@
continue;
}
mtx_unlock(mntvnode_mtx);
- if ((error = vget(vp, lockreq, td)) != 0) {
+ if ((error = vget(vp, lockreq, curthread)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;
How come tha parameters to vget and vput are lopsided like this?
This might have something to do with the commit
of revision 1.218 of ffs_vfsops.c, but I'm not sure.
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: lockmgr panic on shutdown
On Sat, 1 Nov 2003, Doug White wrote:
For giggles I'm rolling back vfs_default.c back to 1.87 since its along
the backtrace path.
This didn't work so -CURRENT is fully broke.
I'd suggest staying on 10/30 not before 4PM PST if you want to not crash
on shutdown.
I suspect I'll need to back up the whole thing to before the commit for
the struct mount locking until jeff kan can straighten things out.
On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote:
I can confirm the lockmgr panic on shutdown reported by someone else
earlier (whose message I mistakenly deleted).
It looks like swapper is trying to undo a lock from pagedaemon and runs
into trouble. This is probably related to the Giant pushdown of
vm_pageout() that alc did last week.
I'm building with INVARIANTS to see if that will catch more info. Will
report back soon.
Just happened me too. I think I see the problem:
When boot() calls sync(), it passes thread0 as the thread argument.
This gets propgated up to ffs_sync, which:
calls vget(), which takes a thread argument.
does some stuff
calls vput(), which does _not_ take a thread argument
The vget() is passed thread0, as passed from boot.
The vput() gets the current thread, which is the process calling boot.
The unlocking in vput is asserting that the same thread that aquired
the lock is releasing it, which seems reasonable.
The obvious solution might be to change line 1161 of ffs_vfsops to
pass vget() curthread rather than td. I assume there's a good
reason why thread0 is passed from boot(), but I can't see why
that's of any use to the vnode locking.
i.e.:
Index: ffs_vfsops.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.221
diff -u -r1.221 ffs_vfsops.c
--- ffs_vfsops.c1 Nov 2003 05:51:54 - 1.221
+++ ffs_vfsops.c2 Nov 2003 03:06:42 -
@@ -1158,7 +1158,7 @@
continue;
}
mtx_unlock(mntvnode_mtx);
- if ((error = vget(vp, lockreq, td)) != 0) {
+ if ((error = vget(vp, lockreq, curthread)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;
How come tha parameters to vget and vput are lopsided like this?
This might have something to do with the commit
of revision 1.218 of ffs_vfsops.c, but I'm not sure.
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: lockmgr panic on shutdown
For giggles I'm rolling back vfs_default.c back to 1.87 since its along
the backtrace path.
This didn't work so -CURRENT is fully broke.
I'd suggest staying on 10/30 not before 4PM PST if you want to not crash
on shutdown.
The patch worked for me. (Well, a slightly modified one: I passed 0 for
the
thread argument to vget: It recognises that as special).
Included here is the patch to both the ffs and default sync operations.
I didn't exercise the default one, but the ffs case is certainly behaving
itself.
Index: kern/vfs_default.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/kern/vfs_default.c,v
retrieving revision 1.89
diff -u -r1.89 vfs_default.c
--- kern/vfs_default.c 1 Nov 2003 05:51:54 - 1.89
+++ kern/vfs_default.c 2 Nov 2003 03:36:03 -
@@ -898,7 +898,7 @@
}
mtx_unlock(mntvnode_mtx);
- if ((error = vget(vp, lockreq, td)) != 0) {
+ if ((error = vget(vp, lockreq, 0)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;
Index: ufs/ffs/ffs_vfsops.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.221
diff -u -r1.221 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c1 Nov 2003 05:51:54 - 1.221
+++ ufs/ffs/ffs_vfsops.c2 Nov 2003 03:22:13 -
@@ -1158,7 +1158,7 @@
continue;
}
mtx_unlock(mntvnode_mtx);
- if ((error = vget(vp, lockreq, td)) != 0) {
+ if ((error = vget(vp, lockreq, 0)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forward: HEADS UP! Default value of ip6_v6only changed
Michael Nottebrock wrote: Christian Weisgerber wrote: If we ship with a default of v6only off, then people will not fix software to open two sockets. This in turn means that turning v6only on will break this software. I find the notion of making people fix their software to not rely on RFC-defined behaviour problematic. I'm actually glad to see NetBSD reversed their unfortunate decision regarding the default (and OpenBSD's stunt of not even providing a knob is very evil indeed). 100% agreed here. The standard exists for a reason. If people find the standard problematic (in fact I concur with Itojun's analysis about IPv4-mapped addresses), they should voice in the appropriate forum to fix the standard rather than just ignore the standard and implement things in their own way, which only creates and/or worsens the compatibility nightmare. (Another test knob into GNU autoconf. Sad.) It's not like IETF RFC's are particularly hard to amend, either, at least compared to other standarization bodies. IETF and its folks are *very* open and flexible IMHO. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: lockmgr panic on shutdown
On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote: For giggles I'm rolling back vfs_default.c back to 1.87 since its along the backtrace path. This didn't work so -CURRENT is fully broke. I'd suggest staying on 10/30 not before 4PM PST if you want to not crash on shutdown. The patch worked for me. (Well, a slightly modified one: I passed 0 for the thread argument to vget: It recognises that as special). kan came up with a different patch that changes the vput in ffs_vfsops:ffs_sync with a vrele. That should be committed shortly. Since he's been working in that area I'll defer to him :) Included here is the patch to both the ffs and default sync operations. I didn't exercise the default one, but the ffs case is certainly behaving itself. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: lockmgr panic on shutdown
On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote: The obvious solution might be to change line 1161 of ffs_vfsops to pass vget() curthread rather than td. I assume there's a good reason why thread0 is passed from boot(), but I can't see why that's of any use to the vnode locking. Passing thread0 in boot() is a quick (and not even wrong) fix for the problem that there is no valid current process^Wthread in the panic case. Long ago in Net/2 (still in Lite2 for at least the i386 version), sync() in boot() was passed the completely bogus parameters ((struct sigcontext *)0) (instead of (p, uap, retval). This worked to the extent that sync()'s proc pointer was not passed further or not dereferenced. Now there are lots of locks, and since thread0 is never the corerect lock holder, things work at most to the extent that sync()'s proc pointer is not passed further. curthread is never null in -current, so upgrading to the version that passes it (i386/i386/machdep.c 1.111 (actually passes curproc)) would probably help in the non-panic case without increasing bugs for the panic case. However, passing curthread is still wrong for the panic case due to the following complications: - panics may occur during context switches or in other critical regions when curthread is not quite current. - under SMP, curthread is per-CPU, so having it non-null doesn't really help. Locks may be held by curproc's running on other CPUs, and in panic() it is difficult to handle the other CPUs correctly -- if you stop them then they won't be able to release their locks, and if you let them run they may run into you. Hopefully in the case of a normal shutdown all the other CPUs release their locks and stop before the sync(). Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Dualbooting STABLE CURRENT
I need some help dual booting STABLE CURRENT. I have two SCSI disks with: STABLE taking the entire first disk (works fine) CURRENT taking the first 1/3 of the second disk and backup data taking the remaining 2/3 of the second disk. I have installed CURRENT (at least 8 times) but I cannot get it to boot. Choosing F1 on booteasy boots STABLE. Choosing F5 boots nothing but it then shows an F2 entry for FreeBSD. I choose F2 and nothing happens. I have tried boot easy on the first disk, the second disk, both disks and nothing seems to work. I have tried making both slices making bootable and every possible derivative I can think of. What am I missing here? +-+ |Steve Wingate [EMAIL PROTECTED] |MCSE, CCNA Sat Nov 1 13:10:00 PST 2003 +-+ |FreeBSD 4.9-STABLE | 1:10PM up 2 days, 5:17, 0 users, load averages: 0.00, 0.00, 0.00 +-+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
On Sat, 1 Nov 2003, Steve Wingate wrote: I need some help dual booting STABLE CURRENT. I have two SCSI disks with: STABLE taking the entire first disk (works fine) CURRENT taking the first 1/3 of the second disk and backup data taking the remaining 2/3 of the second disk. I have installed CURRENT (at least 8 times) but I cannot get it to boot. Choosing F1 on booteasy boots STABLE. Choosing F5 boots nothing but it then shows an F2 entry for FreeBSD. I choose F2 and nothing happens. I have tried boot easy on the first disk, the second disk, both disks and nothing seems to work. I have tried making both slices making bootable and every possible derivative I can think of. What am I missing here? Try to install booteasy from STABLE, only from STABLE, to both harddisk. don't install booteasy when install CURRENT or try to recover boot easy from STABLE on the second hardisk as described in the handbook it works for me sham khalil ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
Try to install booteasy from STABLE, only from STABLE, to both harddisk. don't install booteasy when install CURRENT or try to recover boot easy from STABLE on the second hardisk as described in the handbook it works for me sham khalil I have tried this and it still doesn't boot to CURRENT. +-+ |Steve Wingate [EMAIL PROTECTED] |MCSE, CCNA Sat Nov 1 16:10:00 PST 2003 +-+ |FreeBSD 4.9-STABLE | 4:10PM up 2 days, 8:17, 0 users, load averages: 0.00, 0.00, 0.00 +-+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
On Sat, 1 Nov 2003, Steve Wingate wrote: I need some help dual booting STABLE CURRENT. I have two SCSI disks with: STABLE taking the entire first disk (works fine) CURRENT taking the first 1/3 of the second disk and backup data taking the remaining 2/3 of the second disk. I have installed CURRENT (at least 8 times) but I cannot get it to boot. Choosing F1 on booteasy boots STABLE. Choosing F5 boots nothing but it then shows an F2 entry for FreeBSD. I choose F2 and nothing happens. I have tried boot easy on the first disk, the second disk, both disks and nothing seems to work. I have tried making both slices making bootable and every possible derivative I can think of. What am I missing here? Nothing happens probably means its beeping but I can't hear it :) If that happens, its because boot0 and the BIOS can't figure out how to reach the partition, generally because the geometry is wrong. Try zeroing off the front end of the disk, partitioning it with DOS FDISK, then put FreeBSD on it. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
Nothing happens probably means its beeping but I can't hear it :) If that happens, its because boot0 and the BIOS can't figure out how to reach the partition, generally because the geometry is wrong. Try zeroing off the front end of the disk, partitioning it with DOS FDISK, then put FreeBSD on it. I don't like the sound of that. I'll just stick with STABLE until 5.x is really ready. +-+ |Steve Wingate [EMAIL PROTECTED] |MCSE, CCNA Sat Nov 1 19:40:00 PST 2003 +-+ |FreeBSD 4.9-STABLE | 7:40PM up 2 days, 11:47, 0 users, load averages: 0.00, 0.00, 0.00 +-+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
On Sat, 1 Nov 2003, Steve Wingate wrote: Nothing happens probably means its beeping but I can't hear it :) If that happens, its because boot0 and the BIOS can't figure out how to reach the partition, generally because the geometry is wrong. Try zeroing off the front end of the disk, partitioning it with DOS FDISK, then put FreeBSD on it. I don't like the sound of that. I'll just stick with STABLE until 5.x is really ready. -STABLE will have the same problem since its in boot0 and the BIOS, not the OS on the partition its trying to boot. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dualbooting STABLE CURRENT
I don't like the sound of that. I'll just stick with STABLE until 5.x is really ready. -STABLE will have the same problem since its in boot0 and the BIOS, not the OS on the partition its trying to boot. Actually STABLE will have no problems as it's been running on this box for over a year. +-+ |Steve Wingate [EMAIL PROTECTED] |MCSE, CCNA Sat Nov 1 20:30:00 PST 2003 +-+ |FreeBSD 4.9-STABLE | 8:30PM up 2 days, 12:37, 1 user, load averages: 0.00, 0.00, 0.00 +-+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
