Re: Error 1: gpart create -s GPT ad0
В Sat, 13 Nov 2010 09:35:14 +0200 Ivan Klymenko fi...@ukr.net пишет: В Fri, 12 Nov 2010 22:09:30 -0500 Kris Moore k...@pcbsd.org пишет: On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: Hello! People. I use the alternate installer pc-sysinstall based on FreeBSD 9.0-CURRENT r215176 When you load the virtual machine qemu disk ad0 is determined by: http://img573.imageshack.us/i/qemu1.png/ but when trying to create a section displays the following error: http://img80.imageshack.us/i/qemu.png/ Think all options for gpart are correct - what can there be a problem? Thanks! The gpart syntax looks correct, and ad0 is being used elsewhere in your install process successfully. Is this a fresh disk / image? Perhaps something has broken in the gpart command? Thank you! Now try to recreate the virtual disk ... But it did not help avoid the problem :( ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 1: gpart create -s GPT ad0
On 13.11.2010 10:34, Ivan Klymenko wrote: Hmm, are you sure that your kernel is based on r215176? no doubt! :) Do you use custom ISO image? Can you mount it and show output of command: # ident /mnt/boot/kernel/kernel.symbols | grep g_part.c -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
В Fri, 12 Nov 2010 20:02:08 -0800 Garrett Cooper gcoo...@freebsd.org пишет: On Fri, Nov 12, 2010 at 7:09 PM, Kris Moore k...@pcbsd.org wrote: On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: Hello! People. I use the alternate installer pc-sysinstall based on FreeBSD 9.0-CURRENT r215176 When you load the virtual machine qemu disk ad0 is determined by: http://img573.imageshack.us/i/qemu1.png/ but when trying to create a section displays the following error: http://img80.imageshack.us/i/qemu.png/ Think all options for gpart are correct - what can there be a problem? Thanks! The gpart syntax looks correct, and ad0 is being used elsewhere in your install process successfully. Is this a fresh disk / image? Perhaps something has broken in the gpart command? According to the gpart(8) manpage, the invocation is correct. It'd be interesting to see what the log displayed yields, but before then have you tried kern.geom.debugflags=16? no. after booting the system immediately executed script pc-sysinstall now try to force the kern.geom.debugflags = 16 before running pc-sysinstall I did a quick scan of lib/libgeom and sys/geom, and all of the places (minus one) that returned EINVAL were due to incorrect sector size. What are you using for your disk? Thanks, -Garrett I'm afraid I do not quite understand the essence last question ... : ( I created a virtual disk command: qemu-img create name_disk.img 40G All the breakdown of disk partitions running script pc-sysinstall in accordance with my config file pcinstall.cfg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
In spirit of Brandon Gooch's mail (although I have lurked whole time) , I'm currently on FreeBSD 8.1-STABLE #0 r215179 amd64, and I'm also willing to test any relevant patches, preferably after consensus is reached. regards, - Jakub Lach -- View this message in context: http://old.nabble.com/Sense-fetching--Was%3A-cdrtools--devel-...--tp30144086p30205790.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/pc98
TB --- 2010-11-13 06:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 06:25:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-11-13 06:25:00 - cleaning the object tree TB --- 2010-11-13 06:25:36 - cvsupping the source tree TB --- 2010-11-13 06:25:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-11-13 06:26:02 - building world TB --- 2010-11-13 06:26:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 06:26:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 06:26:02 - TARGET=pc98 TB --- 2010-11-13 06:26:02 - TARGET_ARCH=i386 TB --- 2010-11-13 06:26:02 - TZ=UTC TB --- 2010-11-13 06:26:02 - __MAKE_CONF=/dev/null TB --- 2010-11-13 06:26:02 - cd /src TB --- 2010-11-13 06:26:02 - /usr/bin/make -B buildworld World build started on Sat Nov 13 06:26:02 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Nov 13 08:12:51 UTC 2010 TB --- 2010-11-13 08:12:51 - generating LINT kernel config TB --- 2010-11-13 08:12:51 - cd /src/sys/pc98/conf TB --- 2010-11-13 08:12:51 - /usr/bin/make -B LINT TB --- 2010-11-13 08:12:51 - building LINT kernel TB --- 2010-11-13 08:12:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:12:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:12:51 - TARGET=pc98 TB --- 2010-11-13 08:12:51 - TARGET_ARCH=i386 TB --- 2010-11-13 08:12:51 - TZ=UTC TB --- 2010-11-13 08:12:51 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:12:51 - cd /src TB --- 2010-11-13 08:12:51 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 13 08:12:51 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_iso88025subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_lagg.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_loop.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
[head tinderbox] failure on mips/mips
TB --- 2010-11-13 08:23:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 08:23:58 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-13 08:23:58 - cleaning the object tree TB --- 2010-11-13 08:23:58 - cvsupping the source tree TB --- 2010-11-13 08:23:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-13 08:24:39 - building world TB --- 2010-11-13 08:24:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:24:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:24:39 - TARGET=mips TB --- 2010-11-13 08:24:39 - TARGET_ARCH=mips TB --- 2010-11-13 08:24:39 - TZ=UTC TB --- 2010-11-13 08:24:39 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:24:39 - cd /src TB --- 2010-11-13 08:24:39 - /usr/bin/make -B buildworld /src/Makefile.inc1, line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-13 08:24:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 08:24:40 - ERROR: failed to build world TB --- 2010-11-13 08:24:40 - 2.07 user 5.94 system 41.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 1: gpart create -s GPT ad0
В Sat, 13 Nov 2010 11:01:36 +0300 Andrey V. Elsukov bu7c...@yandex.ru пишет: On 13.11.2010 10:34, Ivan Klymenko wrote: Hmm, are you sure that your kernel is based on r215176? no doubt! :) Do you use custom ISO image? yes. Can you mount it and show output of command: # ident /mnt/boot/kernel/kernel.symbols | grep g_part.c Once mounted iso image of my drive to /mnt ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory because this file (kernel.symbols) is really not in the iso image... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2010-11-13 06:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 06:25:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-11-13 06:25:00 - cleaning the object tree TB --- 2010-11-13 06:25:38 - cvsupping the source tree TB --- 2010-11-13 06:25:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-11-13 06:26:03 - building world TB --- 2010-11-13 06:26:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 06:26:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 06:26:03 - TARGET=i386 TB --- 2010-11-13 06:26:03 - TARGET_ARCH=i386 TB --- 2010-11-13 06:26:03 - TZ=UTC TB --- 2010-11-13 06:26:03 - __MAKE_CONF=/dev/null TB --- 2010-11-13 06:26:03 - cd /src TB --- 2010-11-13 06:26:03 - /usr/bin/make -B buildworld World build started on Sat Nov 13 06:26:04 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Nov 13 08:12:54 UTC 2010 TB --- 2010-11-13 08:12:54 - generating LINT kernel config TB --- 2010-11-13 08:12:54 - cd /src/sys/i386/conf TB --- 2010-11-13 08:12:54 - /usr/bin/make -B LINT TB --- 2010-11-13 08:12:54 - building LINT kernel TB --- 2010-11-13 08:12:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:12:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:12:54 - TARGET=i386 TB --- 2010-11-13 08:12:54 - TARGET_ARCH=i386 TB --- 2010-11-13 08:12:54 - TZ=UTC TB --- 2010-11-13 08:12:54 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:12:54 - cd /src TB --- 2010-11-13 08:12:54 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 13 08:12:54 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_iso88025subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_lagg.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net/if_loop.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-11-13 08:25:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 08:25:49 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-13 08:25:49 - cleaning the object tree TB --- 2010-11-13 08:25:52 - cvsupping the source tree TB --- 2010-11-13 08:25:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-13 08:26:08 - building world TB --- 2010-11-13 08:26:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:26:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:26:08 - TARGET=powerpc TB --- 2010-11-13 08:26:08 - TARGET_ARCH=powerpc64 TB --- 2010-11-13 08:26:08 - TZ=UTC TB --- 2010-11-13 08:26:08 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:26:08 - cd /src TB --- 2010-11-13 08:26:08 - /usr/bin/make -B buildworld World build started on Sat Nov 13 08:26:09 UTC 2010 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap === gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk optionlist options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name=config.h system.h coretypes.h tm.h optionlist options.c TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=auto-host.h ansidecl.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-13 08:30:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-13 08:30:52 - ERROR: failed to build world TB --- 2010-11-13 08:30:52 - 206.48 user 56.21 system 302.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 1: gpart create -s GPT ad0
On 13.11.2010 11:25, Ivan Klymenko wrote: Once mounted iso image of my drive to /mnt ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory because this file (kernel.symbols) is really not in the iso image... So, I can not reproduce this error. And I still think that you use older revision and you should rebuild your ISO image with fresh sources. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
В Sat, 13 Nov 2010 10:10:32 +0200 Ivan Klymenko fi...@ukr.net пишет: В Fri, 12 Nov 2010 20:02:08 -0800 Garrett Cooper gcoo...@freebsd.org пишет: On Fri, Nov 12, 2010 at 7:09 PM, Kris Moore k...@pcbsd.org wrote: On Fri, Nov 12, 2010 at 08:47:00PM +0200, Ivan Klymenko wrote: Hello! People. I use the alternate installer pc-sysinstall based on FreeBSD 9.0-CURRENT r215176 When you load the virtual machine qemu disk ad0 is determined by: http://img573.imageshack.us/i/qemu1.png/ but when trying to create a section displays the following error: http://img80.imageshack.us/i/qemu.png/ Think all options for gpart are correct - what can there be a problem? Thanks! The gpart syntax looks correct, and ad0 is being used elsewhere in your install process successfully. Is this a fresh disk / image? Perhaps something has broken in the gpart command? According to the gpart(8) manpage, the invocation is correct. It'd be interesting to see what the log displayed yields, but before then have you tried kern.geom.debugflags=16? no. after booting the system immediately executed script pc-sysinstall now try to force the kern.geom.debugflags = 16 before running pc-sysinstall did not help ... http://img152.imageshack.us/i/qemu2.png/ on the version of the source code a couple of weeks ago it worked fine I just updated the source tree and recompiled my CD/DVD ISO image... I did a quick scan of lib/libgeom and sys/geom, and all of the places (minus one) that returned EINVAL were due to incorrect sector size. What are you using for your disk? Thanks, -Garrett I'm afraid I do not quite understand the essence last question ... : ( I created a virtual disk command: qemu-img create name_disk.img 40G All the breakdown of disk partitions running script pc-sysinstall in accordance with my config file pcinstall.cfg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 1: gpart create -s GPT ad0
В Sat, 13 Nov 2010 11:34:12 +0300 Andrey V. Elsukov bu7c...@yandex.ru пишет: On 13.11.2010 11:25, Ivan Klymenko wrote: Once mounted iso image of my drive to /mnt ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory because this file (kernel.symbols) is really not in the iso image... So, I can not reproduce this error. And I still think that you use older revision and you should rebuild your ISO image with fresh sources. well ... but it will take a little time ... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 1: gpart create -s GPT ad0
On 13.11.2010 11:40, Ivan Klymenko wrote: So, I can not reproduce this error. And I still think that you use older revision and you should rebuild your ISO image with fresh sources. well ... but it will take a little time ... Just a note - as you may see from tinderbox's emails at the moment building of fresh current is broken :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Error 1: gpart create -s GPT ad0
В Sat, 13 Nov 2010 11:49:29 +0300 Andrey V. Elsukov bu7c...@yandex.ru пишет: On 13.11.2010 11:40, Ivan Klymenko wrote: So, I can not reproduce this error. And I still think that you use older revision and you should rebuild your ISO image with fresh sources. well ... but it will take a little time ... Just a note - as you may see from tinderbox's emails at the moment building of fresh current is broken :) Thanks! I saw it - watch for the mailing too ;) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 1: gpart create -s GPT ad0
В Sat, 13 Nov 2010 08:38:16 +0300 Andrey V. Elsukov bu7c...@yandex.ru пишет: On 12.11.2010 21:47, Ivan Klymenko wrote: http://img80.imageshack.us/i/qemu.png/ Think all options for gpart are correct - what can there be a problem? This was temporary regression and it is fixed now in r215118. In any case it is harmless. I am ashamed ... :( You were right! I have an ISO audit r215110 ... Is the current system on a PC r215176 now try to rebuild the ISO it ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Call for Area SATA II RAID controller testers [Fwd: svn commit: r215234 - head/sys/dev/arcmsr]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I have just committed a new vendor release of arcmsr(4) driver. This is intended for 8.2-RELEASE so please test if you could. Thanks in advance! (Note: I have a tarball at http://people.freebsd.org/~delphij/misc/arcmsr.tar.xz which can be used for 8.x system, untar over /usr/src and rebuild the kernel or module depending on your configuration). - Original Message Subject: svn commit: r215234 - head/sys/dev/arcmsr Date: Sat, 13 Nov 2010 08:58:36 + (UTC) From: Xin LI delp...@freebsd.org To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Author: delphij Date: Sat Nov 13 08:58:36 2010 New Revision: 215234 URL: http://svn.freebsd.org/changeset/base/215234 Log: Update to vendor release 1.20.00.19. Bug fixes: * Fixed inquiry data fails comparion at DV1 step * Fixed bad range input in bus_alloc_resource for ADAPTER_TYPE_B * Fixed arcmsr driver prevent arcsas support for Areca SAS HBA ARC13x0 Many thanks to Areca for continuing to support FreeBSD. This commit is intended for MFC before 8.2-RELEASE. Submitted by: Ching-Lung Huang ching2048 areca com tw -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM3lRTAAoJEATO+BI/yjfBs3wH/24ViOUPwdDjr9lDsX6RaWCQ Ux+9YsekrXLVks61zH8B1dW1rXmthk+aiXpE223UYkcb2M5sLgOQCBYlSDoSwJXu q8iLLZ9Dg6hWpLiS1u6sCj3jjsQbsDVuW1BCrCTSr/eOp6AbXI19GEDouPxVKkt3 wc1amh3eo6ZQAWnxksk+6/HK4nGJOQhjuEC8llybSsImeqqzoEGhRyqJVGa3NO7q fZfTX108QItRmx9Uavh3/2Sa4WA9RWWky+QUSg3hPZg1kNSYJOHuCHgEQIGEE+9R qG38IjHP+NPw0jZVAE7Qap0rA/iMY5FOKeLTjH0PvRBsFeRiPP22KRvdf8eQBM8= =X4q7 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
Brandon Gooch wrote: 2010/11/5 Alexander Motin m...@freebsd.org: Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. Hey mav, sorry to chime in after so long here, but have some of these patches been committed (as of r215179)? Which patches are still applicable for testing? I assume the cdrtools patch for sure... Now uncommitted pass_autosence.patch and possibly cdrtools.patch. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-11-13 08:24:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 08:24:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-11-13 08:24:40 - cleaning the object tree TB --- 2010-11-13 08:25:01 - cvsupping the source tree TB --- 2010-11-13 08:25:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-11-13 08:25:18 - building world TB --- 2010-11-13 08:25:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 08:25:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 08:25:18 - TARGET=powerpc TB --- 2010-11-13 08:25:18 - TARGET_ARCH=powerpc TB --- 2010-11-13 08:25:18 - TZ=UTC TB --- 2010-11-13 08:25:18 - __MAKE_CONF=/dev/null TB --- 2010-11-13 08:25:18 - cd /src TB --- 2010-11-13 08:25:18 - /usr/bin/make -B buildworld World build started on Sat Nov 13 08:25:18 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Nov 13 10:04:58 UTC 2010 TB --- 2010-11-13 10:04:58 - generating LINT kernel config TB --- 2010-11-13 10:04:58 - cd /src/sys/powerpc/conf TB --- 2010-11-13 10:04:58 - /usr/bin/make -B LINT TB --- 2010-11-13 10:04:58 - building LINT kernel TB --- 2010-11-13 10:04:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 10:04:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 10:04:58 - TARGET=powerpc TB --- 2010-11-13 10:04:58 - TARGET_ARCH=powerpc TB --- 2010-11-13 10:04:58 - TZ=UTC TB --- 2010-11-13 10:04:58 - __MAKE_CONF=/dev/null TB --- 2010-11-13 10:04:58 - cd /src TB --- 2010-11-13 10:04:58 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 13 10:04:59 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_iso88025subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_lagg.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/net/if_loop.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param
Re: www/chromium crashing whole system
On Fri, Nov 12, 2010 at 10:37:15PM +, Alexander Best wrote: hi there, i'm having an issue with www/chromium. sometimes it will completely lock up my system without producing a core dump. i'm running HEAD (r215102; amd64). Core dump of the kernel or the process ? You probably should follow the usual procedure for the deadlock debugging, see dev handbook. this time however chrome.core made it to disk somehow: ... Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008026d76a2 in symlook_default (name=0x806797dbc __sys_sigreturn, hash=92647454, refobj=0x802722c00, defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 Please show the output of info locals in the frame 0. 2675 symp = symlook_list(name, hash, list_main, obj, ventry, flags, [New Thread 2ee6b40 (LWP 100245)] [New Thread 2ee6000 (LWP 100212)] (gdb) bt #0 0x0008026d76a2 in symlook_default (name=0x806797dbc __sys_sigreturn, hash=92647454, refobj=0x802722c00, defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675 #1 0x0008026d815c in find_symdef (symnum=217, refobj=0x802722c00, defobj_out=0x7fbfe1a8, flags=1, cache=0x0) at /usr/src/libexec/rtld-elf/rtld.c:1205 #2 0x0008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable reloff is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:557 #3 0x0008026d487d in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 #4 0x91969eb2 in ?? () #5 0x in ?? () #6 0x in ?? () #7 0xfbd0 in ?? () #8 0x7fbfe260 in ?? () #9 0x7fbfe260 in ?? () #10 0x in ?? () #11 0x02ee6000 in ?? () #12 0x02ee6cb8 in ?? () #13 0x0206 in ?? () #14 0x in ?? () #15 0x000802722c00 in ?? () #16 0x0024 in ?? () #17 0x00080679fc26 in handle_signal (actp=Variable actp is not available. ) at /usr/src/lib/libthr/thread/thr_sig.c:254 #18 0x00080679fd5f in thr_sighandler (sig=20, info=0x7fbfea00, _ucp=0x7fbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181 #19 signal handler called #20 0x0008069cad6c in read () at read.S:3 #21 0x00080679dc70 in __read (fd=15, buf=0x7fbfef84, nbytes=4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460 #22 0x0043871f in (anonymous namespace)::ShutdownDetector::ThreadMain () #23 0x00984caa in ThreadFunc () #24 0x00080679b81e in thread_start (curthread=0x2ee6b40) at /usr/src/lib/libthr/thread/thr_create.c:273 #25 0x in ?? () Cannot access memory at address 0x7fbff000 cheers. alex -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org pgpztqhkBgnSv.pgp Description: PGP signature
Re: www/chromium crashing whole system
On Sat Nov 13 10, Kostik Belousov wrote:
On Fri, Nov 12, 2010 at 10:37:15PM +, Alexander Best wrote:
hi there,
i'm having an issue with www/chromium. sometimes it will completely lock up
my
system without producing a core dump. i'm running HEAD (r215102; amd64).
Core dump of the kernel or the process ?
a kernel core dump never gets produced. and this is the first time a process
dump made it to disk.
You probably should follow the usual procedure for the deadlock
debugging, see dev handbook.
i have all those options in my kernel conf. still the computer just locks up
without any chance to enter the debugger. nothing works any longer.
this time however chrome.core made it to disk somehow:
...
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
Please show the output of info locals in the frame 0.
(gdb) frame 0
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc __sys_sigreturn,
hash=92647454, refobj=0x802722c00, defobj_out=0x7fbfe160,
ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675
2675symp = symlook_list(name, hash, list_main, obj, ventry, flags,
(gdb) info locals
donelist = {objs = 0x7fbfde90, num_alloc = 64, num_used = 0}
def = (const Elf_Sym *) 0x0
symp = (const Elf_Sym *) 0x7fbfe0e0
obj = Variable obj is not available.
cheers.
alex
2675symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
[New Thread 2ee6b40 (LWP 100245)]
[New Thread 2ee6000 (LWP 100212)]
(gdb) bt
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
#1 0x0008026d815c in find_symdef (symnum=217, refobj=0x802722c00,
defobj_out=0x7fbfe1a8, flags=1, cache=0x0) at
/usr/src/libexec/rtld-elf/rtld.c:1205
#2 0x0008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable
reloff is not available.
) at /usr/src/libexec/rtld-elf/rtld.c:557
#3 0x0008026d487d in _rtld_bind_start () at
/usr/src/libexec/rtld-elf/amd64/rtld_start.S:99
#4 0x91969eb2 in ?? ()
#5 0x in ?? ()
#6 0x in ?? ()
#7 0xfbd0 in ?? ()
#8 0x7fbfe260 in ?? ()
#9 0x7fbfe260 in ?? ()
#10 0x in ?? ()
#11 0x02ee6000 in ?? ()
#12 0x02ee6cb8 in ?? ()
#13 0x0206 in ?? ()
#14 0x in ?? ()
#15 0x000802722c00 in ?? ()
#16 0x0024 in ?? ()
#17 0x00080679fc26 in handle_signal (actp=Variable actp is not
available.
) at /usr/src/lib/libthr/thread/thr_sig.c:254
#18 0x00080679fd5f in thr_sighandler (sig=20, info=0x7fbfea00,
_ucp=0x7fbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181
#19 signal handler called
#20 0x0008069cad6c in read () at read.S:3
#21 0x00080679dc70 in __read (fd=15, buf=0x7fbfef84, nbytes=4) at
/usr/src/lib/libthr/thread/thr_syscalls.c:460
#22 0x0043871f in (anonymous
namespace)::ShutdownDetector::ThreadMain ()
#23 0x00984caa in ThreadFunc ()
#24 0x00080679b81e in thread_start (curthread=0x2ee6b40) at
/usr/src/lib/libthr/thread/thr_create.c:273
#25 0x in ?? ()
Cannot access memory at address 0x7fbff000
cheers.
alex
--
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On Sat, Nov 13, 2010 at 11:59:00AM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Fri, Nov 12, 2010 at 10:37:15PM +, Alexander Best wrote:
hi there,
i'm having an issue with www/chromium. sometimes it will completely lock
up my
system without producing a core dump. i'm running HEAD (r215102; amd64).
Core dump of the kernel or the process ?
a kernel core dump never gets produced. and this is the first time a process
dump made it to disk.
You probably should follow the usual procedure for the deadlock
debugging, see dev handbook.
i have all those options in my kernel conf. still the computer just locks up
without any chance to enter the debugger. nothing works any longer.
Do you use serial or firewire console ? Since you run chromium, you
should run X server, and you cannot use syscons for ddb while in X.
this time however chrome.core made it to disk somehow:
...
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
Please show the output of info locals in the frame 0.
(gdb) frame 0
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
2675 symp = symlook_list(name, hash, list_main, obj, ventry, flags,
(gdb) info locals
donelist = {objs = 0x7fbfde90, num_alloc = 64, num_used = 0}
def = (const Elf_Sym *) 0x0
Right, this is what I suspected. def is NULL, but the code path selected
seems to be the one which happens when def != NULL. This is either a
random memory corruption inside the process, or might be some other
usermode issue. It is very unlikely that it has anything with kernel
deadlock.
symp = (const Elf_Sym *) 0x7fbfe0e0
obj = Variable obj is not available.
cheers.
alex
2675 symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
[New Thread 2ee6b40 (LWP 100245)]
[New Thread 2ee6000 (LWP 100212)]
(gdb) bt
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
#1 0x0008026d815c in find_symdef (symnum=217, refobj=0x802722c00,
defobj_out=0x7fbfe1a8, flags=1, cache=0x0) at
/usr/src/libexec/rtld-elf/rtld.c:1205
#2 0x0008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable
reloff is not available.
) at /usr/src/libexec/rtld-elf/rtld.c:557
#3 0x0008026d487d in _rtld_bind_start () at
/usr/src/libexec/rtld-elf/amd64/rtld_start.S:99
#4 0x91969eb2 in ?? ()
#5 0x in ?? ()
#6 0x in ?? ()
#7 0xfbd0 in ?? ()
#8 0x7fbfe260 in ?? ()
#9 0x7fbfe260 in ?? ()
#10 0x in ?? ()
#11 0x02ee6000 in ?? ()
#12 0x02ee6cb8 in ?? ()
#13 0x0206 in ?? ()
#14 0x in ?? ()
#15 0x000802722c00 in ?? ()
#16 0x0024 in ?? ()
#17 0x00080679fc26 in handle_signal (actp=Variable actp is not
available.
) at /usr/src/lib/libthr/thread/thr_sig.c:254
#18 0x00080679fd5f in thr_sighandler (sig=20, info=0x7fbfea00,
_ucp=0x7fbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181
#19 signal handler called
#20 0x0008069cad6c in read () at read.S:3
#21 0x00080679dc70 in __read (fd=15, buf=0x7fbfef84, nbytes=4) at
/usr/src/lib/libthr/thread/thr_syscalls.c:460
#22 0x0043871f in (anonymous
namespace)::ShutdownDetector::ThreadMain ()
#23 0x00984caa in ThreadFunc ()
#24 0x00080679b81e in thread_start (curthread=0x2ee6b40) at
/usr/src/lib/libthr/thread/thr_create.c:273
#25 0x in ?? ()
Cannot access memory at address 0x7fbff000
cheers.
alex
--
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
a13x
pgpAOzSdK1BEt.pgp
Description: PGP signature
Re: www/chromium crashing whole system
On Sat Nov 13 10, Kostik Belousov wrote:
On Sat, Nov 13, 2010 at 11:59:00AM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Fri, Nov 12, 2010 at 10:37:15PM +, Alexander Best wrote:
hi there,
i'm having an issue with www/chromium. sometimes it will completely
lock up my
system without producing a core dump. i'm running HEAD (r215102; amd64).
Core dump of the kernel or the process ?
a kernel core dump never gets produced. and this is the first time a process
dump made it to disk.
You probably should follow the usual procedure for the deadlock
debugging, see dev handbook.
i have all those options in my kernel conf. still the computer just locks up
without any chance to enter the debugger. nothing works any longer.
Do you use serial or firewire console ? Since you run chromium, you
should run X server, and you cannot use syscons for ddb while in X.
nope. all i have is a usb mouse and a usb keyboard. ;)
this time however chrome.core made it to disk somehow:
...
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
Please show the output of info locals in the frame 0.
(gdb) frame 0
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
2675symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
(gdb) info locals
donelist = {objs = 0x7fbfde90, num_alloc = 64, num_used = 0}
def = (const Elf_Sym *) 0x0
Right, this is what I suspected. def is NULL, but the code path selected
seems to be the one which happens when def != NULL. This is either a
random memory corruption inside the process, or might be some other
usermode issue. It is very unlikely that it has anything with kernel
deadlock.
hmmm...but isn't the concept of UNIX that user applications cannot cause a
system to crash (protected mode)?
i tried detaching and attaching my keyboard after chromium crashed my system
and the lights of the keyboard didn't even went on. so in fact everything
crashed and not just X.
cheers.
alex
symp = (const Elf_Sym *) 0x7fbfe0e0
obj = Variable obj is not available.
cheers.
alex
2675symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
[New Thread 2ee6b40 (LWP 100245)]
[New Thread 2ee6000 (LWP 100212)]
(gdb) bt
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
#1 0x0008026d815c in find_symdef (symnum=217, refobj=0x802722c00,
defobj_out=0x7fbfe1a8, flags=1, cache=0x0) at
/usr/src/libexec/rtld-elf/rtld.c:1205
#2 0x0008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable
reloff is not available.
) at /usr/src/libexec/rtld-elf/rtld.c:557
#3 0x0008026d487d in _rtld_bind_start () at
/usr/src/libexec/rtld-elf/amd64/rtld_start.S:99
#4 0x91969eb2 in ?? ()
#5 0x in ?? ()
#6 0x in ?? ()
#7 0xfbd0 in ?? ()
#8 0x7fbfe260 in ?? ()
#9 0x7fbfe260 in ?? ()
#10 0x in ?? ()
#11 0x02ee6000 in ?? ()
#12 0x02ee6cb8 in ?? ()
#13 0x0206 in ?? ()
#14 0x in ?? ()
#15 0x000802722c00 in ?? ()
#16 0x0024 in ?? ()
#17 0x00080679fc26 in handle_signal (actp=Variable actp is not
available.
) at /usr/src/lib/libthr/thread/thr_sig.c:254
#18 0x00080679fd5f in thr_sighandler (sig=20, info=0x7fbfea00,
_ucp=0x7fbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181
#19 signal handler called
#20 0x0008069cad6c in read () at read.S:3
#21 0x00080679dc70 in __read (fd=15, buf=0x7fbfef84, nbytes=4)
at /usr/src/lib/libthr/thread/thr_syscalls.c:460
#22 0x0043871f in (anonymous
namespace)::ShutdownDetector::ThreadMain ()
#23 0x00984caa in ThreadFunc ()
#24 0x00080679b81e in thread_start (curthread=0x2ee6b40) at
/usr/src/lib/libthr/thread/thr_create.c:273
#25 0x in ?? ()
Cannot access memory at address 0x7fbff000
cheers.
alex
--
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On Sat, Nov 13, 2010 at 12:38:46PM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Sat, Nov 13, 2010 at 11:59:00AM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Fri, Nov 12, 2010 at 10:37:15PM +, Alexander Best wrote:
hi there,
i'm having an issue with www/chromium. sometimes it will completely
lock up my
system without producing a core dump. i'm running HEAD (r215102;
amd64).
Core dump of the kernel or the process ?
a kernel core dump never gets produced. and this is the first time a
process
dump made it to disk.
You probably should follow the usual procedure for the deadlock
debugging, see dev handbook.
i have all those options in my kernel conf. still the computer just locks
up
without any chance to enter the debugger. nothing works any longer.
Do you use serial or firewire console ? Since you run chromium, you
should run X server, and you cannot use syscons for ddb while in X.
nope. all i have is a usb mouse and a usb keyboard. ;)
this time however chrome.core made it to disk somehow:
...
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
Please show the output of info locals in the frame 0.
(gdb) frame 0
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
2675 symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
(gdb) info locals
donelist = {objs = 0x7fbfde90, num_alloc = 64, num_used = 0}
def = (const Elf_Sym *) 0x0
Right, this is what I suspected. def is NULL, but the code path selected
seems to be the one which happens when def != NULL. This is either a
random memory corruption inside the process, or might be some other
usermode issue. It is very unlikely that it has anything with kernel
deadlock.
hmmm...but isn't the concept of UNIX that user applications cannot cause a
system to crash (protected mode)?
i tried detaching and attaching my keyboard after chromium crashed my system
and the lights of the keyboard didn't even went on. so in fact everything
crashed and not just X.
If I said it unclear, let me repeat, the usermode crash dump you got
probably has nothing common with the kernel issue.
Kernel problem should be taken care of first, and we cannot move
forward without proper debugging tools (see above).
cheers.
alex
symp = (const Elf_Sym *) 0x7fbfe0e0
obj = Variable obj is not available.
cheers.
alex
2675 symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
[New Thread 2ee6b40 (LWP 100245)]
[New Thread 2ee6000 (LWP 100212)]
(gdb) bt
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
#1 0x0008026d815c in find_symdef (symnum=217,
refobj=0x802722c00, defobj_out=0x7fbfe1a8, flags=1, cache=0x0) at
/usr/src/libexec/rtld-elf/rtld.c:1205
#2 0x0008026d8233 in _rtld_bind (obj=0x802722c00,
reloff=Variable reloff is not available.
) at /usr/src/libexec/rtld-elf/rtld.c:557
#3 0x0008026d487d in _rtld_bind_start () at
/usr/src/libexec/rtld-elf/amd64/rtld_start.S:99
#4 0x91969eb2 in ?? ()
#5 0x in ?? ()
#6 0x in ?? ()
#7 0xfbd0 in ?? ()
#8 0x7fbfe260 in ?? ()
#9 0x7fbfe260 in ?? ()
#10 0x in ?? ()
#11 0x02ee6000 in ?? ()
#12 0x02ee6cb8 in ?? ()
#13 0x0206 in ?? ()
#14 0x in ?? ()
#15 0x000802722c00 in ?? ()
#16 0x0024 in ?? ()
#17 0x00080679fc26 in handle_signal (actp=Variable actp is not
available.
) at /usr/src/lib/libthr/thread/thr_sig.c:254
#18 0x00080679fd5f in thr_sighandler (sig=20,
info=0x7fbfea00, _ucp=0x7fbfe690) at
/usr/src/lib/libthr/thread/thr_sig.c:181
#19 signal handler called
#20 0x0008069cad6c in read () at read.S:3
#21 0x00080679dc70 in __read (fd=15, buf=0x7fbfef84,
nbytes=4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460
#22 0x0043871f in (anonymous
namespace)::ShutdownDetector::ThreadMain ()
#23 0x00984caa in ThreadFunc ()
#24 0x00080679b81e in thread_start (curthread=0x2ee6b40)
Re: www/chromium crashing whole system
On Sat Nov 13 10, Kostik Belousov wrote:
On Sat, Nov 13, 2010 at 12:38:46PM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Sat, Nov 13, 2010 at 11:59:00AM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Fri, Nov 12, 2010 at 10:37:15PM +, Alexander Best wrote:
hi there,
i'm having an issue with www/chromium. sometimes it will completely
lock up my
system without producing a core dump. i'm running HEAD (r215102;
amd64).
Core dump of the kernel or the process ?
a kernel core dump never gets produced. and this is the first time a
process
dump made it to disk.
You probably should follow the usual procedure for the deadlock
debugging, see dev handbook.
i have all those options in my kernel conf. still the computer just
locks up
without any chance to enter the debugger. nothing works any longer.
Do you use serial or firewire console ? Since you run chromium, you
should run X server, and you cannot use syscons for ddb while in X.
nope. all i have is a usb mouse and a usb keyboard. ;)
this time however chrome.core made it to disk somehow:
...
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
Please show the output of info locals in the frame 0.
(gdb) frame 0
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
2675symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
(gdb) info locals
donelist = {objs = 0x7fbfde90, num_alloc = 64, num_used = 0}
def = (const Elf_Sym *) 0x0
Right, this is what I suspected. def is NULL, but the code path selected
seems to be the one which happens when def != NULL. This is either a
random memory corruption inside the process, or might be some other
usermode issue. It is very unlikely that it has anything with kernel
deadlock.
hmmm...but isn't the concept of UNIX that user applications cannot cause a
system to crash (protected mode)?
i tried detaching and attaching my keyboard after chromium crashed my system
and the lights of the keyboard didn't even went on. so in fact everything
crashed and not just X.
If I said it unclear, let me repeat, the usermode crash dump you got
probably has nothing common with the kernel issue.
oh sorry. indeed i misunderstood you there. well i guess this is the problem
most regular users have. we don't own any serial/firewire consoles. all i can
offer is to add kernel OPTIONS. however none of them seem to be able to prevent
the lock up and instead letting me enter the debugger or trigger a kernel core
dump.
i even have watchdog running, but without any sucess. i guess all i can hope
for is that maybe at some point a kernel dump does make it to disk.
cheers.
alex
Kernel problem should be taken care of first, and we cannot move
forward without proper debugging tools (see above).
cheers.
alex
symp = (const Elf_Sym *) 0x7fbfe0e0
obj = Variable obj is not available.
cheers.
alex
2675symp = symlook_list(name, hash, list_main,
obj, ventry, flags,
[New Thread 2ee6b40 (LWP 100245)]
[New Thread 2ee6000 (LWP 100212)]
(gdb) bt
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
#1 0x0008026d815c in find_symdef (symnum=217,
refobj=0x802722c00, defobj_out=0x7fbfe1a8, flags=1, cache=0x0)
at /usr/src/libexec/rtld-elf/rtld.c:1205
#2 0x0008026d8233 in _rtld_bind (obj=0x802722c00,
reloff=Variable reloff is not available.
) at /usr/src/libexec/rtld-elf/rtld.c:557
#3 0x0008026d487d in _rtld_bind_start () at
/usr/src/libexec/rtld-elf/amd64/rtld_start.S:99
#4 0x91969eb2 in ?? ()
#5 0x in ?? ()
#6 0x in ?? ()
#7 0xfbd0 in ?? ()
#8 0x7fbfe260 in ?? ()
#9 0x7fbfe260 in ?? ()
#10 0x in ?? ()
#11 0x02ee6000 in ?? ()
#12 0x02ee6cb8 in ?? ()
#13 0x0206 in ?? ()
#14 0x in ?? ()
#15 0x000802722c00 in ?? ()
#16 0x0024 in ?? ()
#17 0x00080679fc26 in handle_signal (actp=Variable actp is
Re: www/chromium crashing whole system
On Sat, Nov 13, 2010 at 4:47 AM, Alexander Best arun...@freebsd.org wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Sat, Nov 13, 2010 at 12:38:46PM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Sat, Nov 13, 2010 at 11:59:00AM +, Alexander Best wrote:
On Sat Nov 13 10, Kostik Belousov wrote:
On Fri, Nov 12, 2010 at 10:37:15PM +, Alexander Best wrote:
hi there,
i'm having an issue with www/chromium. sometimes it will
completely lock up my
system without producing a core dump. i'm running HEAD (r215102;
amd64).
Core dump of the kernel or the process ?
a kernel core dump never gets produced. and this is the first time a
process
dump made it to disk.
You probably should follow the usual procedure for the deadlock
debugging, see dev handbook.
i have all those options in my kernel conf. still the computer just
locks up
without any chance to enter the debugger. nothing works any longer.
Do you use serial or firewire console ? Since you run chromium, you
should run X server, and you cannot use syscons for ddb while in X.
nope. all i have is a usb mouse and a usb keyboard. ;)
this time however chrome.core made it to disk somehow:
...
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
Please show the output of info locals in the frame 0.
(gdb) frame 0
#0 0x0008026d76a2 in symlook_default (name=0x806797dbc
__sys_sigreturn, hash=92647454, refobj=0x802722c00,
defobj_out=0x7fbfe160, ventry=0x802717790, flags=1) at
/usr/src/libexec/rtld-elf/rtld.c:2675
2675 symp = symlook_list(name, hash, list_main, obj,
ventry, flags,
(gdb) info locals
donelist = {objs = 0x7fbfde90, num_alloc = 64, num_used = 0}
def = (const Elf_Sym *) 0x0
Right, this is what I suspected. def is NULL, but the code path selected
seems to be the one which happens when def != NULL. This is either a
random memory corruption inside the process, or might be some other
usermode issue. It is very unlikely that it has anything with kernel
deadlock.
hmmm...but isn't the concept of UNIX that user applications cannot cause a
system to crash (protected mode)?
i tried detaching and attaching my keyboard after chromium crashed my
system
and the lights of the keyboard didn't even went on. so in fact everything
crashed and not just X.
If I said it unclear, let me repeat, the usermode crash dump you got
probably has nothing common with the kernel issue.
oh sorry. indeed i misunderstood you there. well i guess this is the problem
most regular users have. we don't own any serial/firewire consoles. all i can
offer is to add kernel OPTIONS. however none of them seem to be able to
prevent
the lock up and instead letting me enter the debugger or trigger a kernel core
dump.
i even have watchdog running, but without any sucess. i guess all i can hope
for is that maybe at some point a kernel dump does make it to disk.
If userland hasn't completely locked up, you could login remotely,
i.e. ssh, and poke at the box (if even for a brief period of time
before it goes down).
HTH,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
Hello. scgcheck after applying all patches: Ready to start test for second SCSI open? Enter CR to continue: First SCSI open OK - device usable ** Checking for second SCSI open. Second SCSI open for same device succeeded, 1 additional file descriptor(s) used. Second SCSI open is usable Closing second SCSI. Checking first SCSI. First SCSI open is still usable -- Second SCSI open test PASSED. First SCSI open is still usable Ready to start test for succeeded command? Enter CR to continue: ** Checking for succeeded SCSI command. Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.002s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 48 4C 2D 44 54 2D 53 54 44 56 44 52 41 4D 20 47 53 41 2D 55 32 30 4E 20 48 58 31 31 -- SCSI succeeded command test PASSED Ready to start test for failing command? Enter CR to continue: ** Testing for failed SCSI command. scgcheck: Input/output error. inquiry: scsi sendcmd: retryable error CDB: 12 00 00 FF 24 00 status: 0x0 (GOOD STATUS) resid: 36 cmd finished after 0.038s timeout 40s -- SCSI Transport return != SCG_NO_ERROR (1) -- SCSI status byte set to 0 (0x0) -- SCSI failed command test FAILED Ready to start test for sense data count? Enter CR to continue: ** Testing for SCSI sense data count. ** Testing if at least CCS_SENSE_LEN (18) is supported... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0x00: expected: 18 reported: 18 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0xFF: expected: 18 reported: 18 max found: 18 -- Wanted 18 sense bytes, got it. ** Testing for 32 bytes of sense data... Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0x00: expected: 32 reported: 32 max found: 0 Sense Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Method 0xFF: expected: 32 reported: 32 max found: 32 -- Wanted 32 sense bytes, got it. -- Got a maximum of 32 sense bytes -- SCSI sense count test PASSED -- SCSI status byte test NOT YET READY Ready to start test for working DMA residual count? Enter CR to continue: ** Testing for working DMA residual count. ** Testing for working DMA residual count == 0. CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) CDB cnt: 36 DMA cnt: 36 got really: 36 (System says: RDMA cnt: 36 resid 0) -- Wanted 36 bytes, got it. -- SCSI DMA residual count == 0 test PASSED Ready to start test for working DMA residual count == DMA count? Enter CR to continue: resid: 36 CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 0 resid 36) resid: 36 CDB cnt: 0 DMA cnt: 36 got really: 0 (System says: RDMA cnt: 0 resid 36) -- Wanted 0 bytes, got it. -- SCSI DMA residual count == DMA count test PASSED Ready to start test for working DMA residual count == 1? Enter CR to continue: ** Testing for working DMA residual count == 1. resid: 1 CDB cnt: 36 DMA cnt: 37 got really: 36 (System says: RDMA cnt: 36 resid 1) resid: 1 CDB cnt: 36 DMA cnt: 37 got really: 36 (System says: RDMA cnt: 36 resid 1) -- Wanted 36 bytes, got it. -- SCSI DMA residual count == 1 test PASSED Ready to start test for working DMA overrun detection? Enter CR to continue: ** Testing for working DMA overrun detection. DMA overrun, resid: -1 CDB cnt: 36 DMA cnt: 35 got really: 36 (System says: RDMA cnt: 36 resid -1) DMA overrun, resid: -1 CDB cnt: 36 DMA cnt: 35 got really: 36 (System says: RDMA cnt: 36 resid -1) -- Wanted 36 bytes, got it - DMA overrun not blocked. -- Wanted 35 bytes, got (36) -- Libscg says 35 bytes but got (36) -- SCSI DMA overrun test FAILED -- SCSI transport code test NOT YET READY What is more important, writing CD-Rs and DVD-Rs works. Thanks for help, - Jakub Lach -- View this message in context: http://old.nabble.com/Sense-fetching--Was%3A-cdrtools--devel-...--tp30144086p30206153.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel.
TEKEN_XTERM turns on xterm mode. I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in /etc/ttys. When I executed vim on a console, the keyboard acted weirdly. After setting TERM back to cons25 again, vim acted normally again on consoles. I could assign xterm console characters in /etc/termcap to fkeys by writing keychanges=fkeycode consolecharacter in /etc/rc.conf, but it is just a quick hack, and it is just a solution for me but not for everyone. I would be glad keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel. If the keymaps in consoles and X11 are the same, 99% of configurations I needed to make in applications will be unneeded. It will benefit everyone. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error 1: gpart create -s GPT ad0
В Sat, 13 Nov 2010 11:03:00 +0200 Ivan Klymenko fi...@ukr.net пишет: В Sat, 13 Nov 2010 08:38:16 +0300 Andrey V. Elsukov bu7c...@yandex.ru пишет: On 12.11.2010 21:47, Ivan Klymenko wrote: http://img80.imageshack.us/i/qemu.png/ Think all options for gpart are correct - what can there be a problem? This was temporary regression and it is fixed now in r215118. In any case it is harmless. I am ashamed ... :( You were right! I have an ISO audit r215110 ... Is the current system on a PC r215176 now try to rebuild the ISO it I rebuild the ISO image based on r215176 and gpart did not return an error. Thank you all! Topic can be closed. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel.
On 13 November 2010 15:52, crocket crockabisc...@yahoo.com wrote: TEKEN_XTERM turns on xterm mode. I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in /etc/ttys. When I executed vim on a console, the keyboard acted weirdly. After setting TERM back to cons25 again, vim acted normally again on consoles. I could assign xterm console characters in /etc/termcap to fkeys by writing keychanges=fkeycode consolecharacter in /etc/rc.conf, but it is just a quick hack, and it is just a solution for me but not for everyone. Oh... you can do `vidcontrol -T xterm` and your keybindings will be correct. I would be glad keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel. If the keymaps in consoles and X11 are the same, 99% of configurations I needed to make in applications will be unneeded. It will benefit everyone. As Ed said some days before, you should use TEKEN_XTERM _or_ TEKEN_CONS25 in your kernel. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel.
* crocket crockabisc...@yahoo.com, 20101113 13:52: TEKEN_XTERM turns on xterm mode. I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in /etc/ttys. When I executed vim on a console, the keyboard acted weirdly. Keep in mind that this list is supposed to discuss FreeBSD -CURRENT; not FreeBSD 8.x. Please don't use xterm mode on FreeBSD 8. It doesn't come with any support whatsoever. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp07pH8M2FcF.pgp Description: PGP signature
Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel.
--- On Sat, 11/13/10, Eir Nym eir...@gmail.com wrote: From: Eir Nym eir...@gmail.com Subject: Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel. To: crocket crockabisc...@yahoo.com Cc: freebsd-current@freebsd.org Date: Saturday, November 13, 2010, 4:54 PM On 13 November 2010 15:52, crocket crockabisc...@yahoo.com wrote: TEKEN_XTERM turns on xterm mode. I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in /etc/ttys. When I executed vim on a console, the keyboard acted weirdly. After setting TERM back to cons25 again, vim acted normally again on consoles. I could assign xterm console characters in /etc/termcap to fkeys by writing keychanges=fkeycode consolecharacter in /etc/rc.conf, but it is just a quick hack, and it is just a solution for me but not for everyone. Oh... you can do `vidcontrol -T xterm` and your keybindings will be correct. When I execute 'vidcontrol -T xterm', vidcontrol: illegal option -- T is displayed. Ah, I use FreeBSD 8.1-RELEASE, not -CURRENT. Maybe that's why I don't have -T option. I posted my message here because development of TEKEN_XTERM is an ongoing process. I would be glad keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel. If the keymaps in consoles and X11 are the same, 99% of configurations I needed to make in applications will be unneeded. It will benefit everyone. As Ed said some days before, you should use TEKEN_XTERM _or_ TEKEN_CONS25 in your kernel. I don't understand what you answered to. However, TEKEN_CONS25 is not in my kernel configuration. And There was a typo. I would be glad keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel should be I would be glad if keymaps in X11 and consoles became the same with TEKEN_XTERM in the kernel Do you think xterm way(instead of syscons way) of key symbol to console character conversion should become the default in 9.0-RELEASE? I think it should be since syscons is being replaced by teken, which uses xterm. I'm not sure if I used terms right. PS. teken reminds me of tekken, an arcade game. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel.
Does Delete key match \E[3~ on FreeBSD-CURRENT xterm mode? It's nice to see backspace key match ^?(ASCII DEL), too, since ^H(Ctrl-H) is reserved by such applications as vim and emacs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin m...@freebsd.org wrote: Brandon Gooch wrote: 2010/11/5 Alexander Motin m...@freebsd.org: Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. Hey mav, sorry to chime in after so long here, but have some of these patches been committed (as of r215179)? Which patches are still applicable for testing? I assume the cdrtools patch for sure... Now uncommitted pass_autosence.patch and possibly cdrtools.patch. OK. Patched kernel and cdrtools has resulted in a working cdrecord (burned an ISO successfully) and an endless stream of: ... (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error ... ad infinitum until I start cdrecord: (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data cdrecord output: bran...@x300:~$ sudo cdrecord dev=0,0,0 Fedora-14-i686-Live-Desktop.iso (11-13 11:41) cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Jörg Schilling scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Using libscg version 'schily-0.9'. Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'MATSHITA' Identifikation : 'DVD-RAM UJ-844 ' Revision : 'RC02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO cdrecord: Warning: Cannot read drive buffer. cdrecord: Warning: The DMA speed test has been skipped. Starting to write CD/DVD/BD at speed 16 in real SAO mode for single session. Last chance to quit, starting real write0 seconds. Operation starts. Turning BURN-Free off cdrecord: WARNING: Drive
8-STABLE on -CURRENT with clang?
Has anyone else tried make buildworld on an 8-STABLE checkout on a recent -CURRENT using clang? I'm seeing failures building GCC and was wondering if this was something messed-up locally and whether it was worth even trying to fix. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel.
On 13/11/2010, crocket crockabisc...@yahoo.com wrote: Does Delete key match \E[3~ on FreeBSD-CURRENT xterm mode? It's nice to see backspace key match ^?(ASCII DEL), too, since ^H(Ctrl-H) is reserved by such applications as vim and emacs. For witch action C-H is reserved in vim(1) ? vim, emacs, zsh, and many others use termcap(5) to determine which key generate which sequence. Please note, that xterm and xterm-colors termcap entries are differs, and last is not usable in FreeBSD-CURRENT TEKEN_XTERM console. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libc_r removal?
hi there, any reason to keep lib/libc_r still around? it has been detached from the build process on all supported branches (r162846; 4 years ago). cheers. alex -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 8-STABLE on -CURRENT with clang?
On Sat Nov 13 10, Tim Kientzle wrote: Has anyone else tried make buildworld on an 8-STABLE checkout on a recent -CURRENT using clang? I'm seeing failures building GCC and was wondering if this was something messed-up locally and whether it was worth even trying to fix. can you check if this is the same issue you are experiencing: http://www.mail-archive.com/freebsd-current@freebsd.org/msg126137.html cheers. alex Tim -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] Unbreak buildworld post-r215254
Looks like buildworld is broken when TARGET/TARGET_ARCH isn't specified:
$ make buildworld
/usr/src/Makefile.inc1, line 127: Malformed conditional
(${TARGET_ARCH} == mips ${TARGET} == mips)
/usr/src/Makefile.inc1, line 128: warning: TARGET_ARCH of mips is
deprecated in favor of mipsel or mipseb
/usr/src/Makefile.inc1, line 134: if-less endif
/usr/src/Makefile.inc1, line 152: Unknown target mipsel:amd64.
*** Error code 1
This change fixed it:
$ svn diff Makefile.inc1
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 215254)
+++ Makefile.inc1 (working copy)
@@ -124,7 +124,8 @@
TARGET=${TARGET_ARCH:C/mipse[lb]/mips/:C/armeb/arm}
.endif
# Legacy names, for a transition period mips:mips - mipsel:mips
-.if ${TARGET_ARCH} == mips ${TARGET} == mips
+.if defined(TARGET_ARCH) defined(TARGET) ${TARGET_ARCH} == mips \
+${TARGET} == mips
.warning TARGET_ARCH of mips is deprecated in favor of mipsel or mipseb
.if defined(TARGET_BIG_ENDIAN)
TARGET_ARCH=mipseb
@@ -133,7 +134,8 @@
.endif
.endif
# arm with TARGET_BIG_ENDIAN - armeb
-.if ${TARGET_ARCH} == arm defined(TARGET_BIG_ENDIAN)
+.if defined(TARGET_ARCH) ${TARGET_ARCH} == arm \
+defined(TARGET_BIG_ENDIAN)
.warning TARGET_ARCH of arm with TARGET_BIG_ENDIAN is deprecated. use armeb
TARGET_ARCH=armeb
.endif
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On Sat, 13 Nov 2010, Alexander Best wrote: i tried detaching and attaching my keyboard after chromium crashed my system and the lights of the keyboard didn't even went on. so in fact everything crashed and not just X. If I said it unclear, let me repeat, the usermode crash dump you got probably has nothing common with the kernel issue. oh sorry. indeed i misunderstood you there. well i guess this is the problem most regular users have. we don't own any serial/firewire consoles. all i can offer is to add kernel OPTIONS. however none of them seem to be able to prevent the lock up and instead letting me enter the debugger or trigger a kernel core dump. i even have watchdog running, but without any sucess. i guess all i can hope for is that maybe at some point a kernel dump does make it to disk. Do you have a second box you can run X11 on, and SSH into the box that will run Chromium? If it is really Chromium triggering the crash, this might allow you to access the console when it crashes. However, if it's Chromium triggering an X11-related crash, it might well not. (Also, it might well not because of timing differences, but it is worth a try). Another thing to consider is starting Chromium when switched to a text virtual console from X11, which would leave you in text mode for DDB, or at least let you see something interesting on the console. If regular crashdumps appear unreliable, try setting up a textdump with an automatic reboot, that might provde more reliable (small chance, but it could). Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On Sat, Nov 13, 2010 at 2:08 PM, Robert Watson rwat...@freebsd.org wrote: On Sat, 13 Nov 2010, Alexander Best wrote: i tried detaching and attaching my keyboard after chromium crashed my system and the lights of the keyboard didn't even went on. so in fact everything crashed and not just X. If I said it unclear, let me repeat, the usermode crash dump you got probably has nothing common with the kernel issue. oh sorry. indeed i misunderstood you there. well i guess this is the problem most regular users have. we don't own any serial/firewire consoles. all i can offer is to add kernel OPTIONS. however none of them seem to be able to prevent the lock up and instead letting me enter the debugger or trigger a kernel core dump. i even have watchdog running, but without any sucess. i guess all i can hope for is that maybe at some point a kernel dump does make it to disk. Do you have a second box you can run X11 on, and SSH into the box that will run Chromium? If it is really Chromium triggering the crash, this might allow you to access the console when it crashes. However, if it's Chromium triggering an X11-related crash, it might well not. (Also, it might well not because of timing differences, but it is worth a try). Another thing to consider is starting Chromium when switched to a text virtual console from X11, which would leave you in text mode for DDB, or at least let you see something interesting on the console. If regular crashdumps appear unreliable, try setting up a textdump with an automatic reboot, that might provde more reliable (small chance, but it could). Isn't there also DEADLKRES that might be helpful in this case (if Alex is really dealing with a livelock in the kernel)...? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On Sat, 13 Nov 2010, Garrett Cooper wrote: Isn't there also DEADLKRES that might be helpful in this case (if Alex is really dealing with a livelock in the kernel)...? The deadlock resolver is compiled into the GENERIC kernel on -CURRENT, so I'm assuming it hasn't helped (or perhaps is even part of the problem). I think the best thing to do at this point is to try to get into DDB. Of the schemes I suggested to work around the X11 issue, switching to a virtual console before starting Chromium may work best, since it will continue to use the local X server, etc. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On 11/13/10 2:08 PM, Robert Watson wrote: On Sat, 13 Nov 2010, Alexander Best wrote: i tried detaching and attaching my keyboard after chromium crashed my system and the lights of the keyboard didn't even went on. so in fact everything crashed and not just X. If I said it unclear, let me repeat, the usermode crash dump you got probably has nothing common with the kernel issue. oh sorry. indeed i misunderstood you there. well i guess this is the problem most regular users have. we don't own any serial/firewire consoles. all i can offer is to add kernel OPTIONS. however none of them seem to be able to prevent the lock up and instead letting me enter the debugger or trigger a kernel core dump. i even have watchdog running, but without any sucess. i guess all i can hope for is that maybe at some point a kernel dump does make it to disk. Do you have a second box you can run X11 on, and SSH into the box that will run Chromium? If it is really Chromium triggering the crash, this might allow you to access the console when it crashes. However, if it's Chromium triggering an X11-related crash, it might well not. (Also, it might well not because of timing differences, but it is worth a try). Another thing to consider is starting Chromium when switched to a text virtual console from X11, which would leave you in text mode for DDB, or at least let you see something interesting on the console. If regular crashdumps appear unreliable, try setting up a textdump with an automatic reboot, that might provde more reliable (small chance, but it could). we did have some people working on an ethernet version of the dcons/remote debugging stuff I guess it only supports a small subset of ethernet chips though.. Anyone know the status of that work? Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On 11/13/10 2:13 PM, Robert Watson wrote: On Sat, 13 Nov 2010, Garrett Cooper wrote: Isn't there also DEADLKRES that might be helpful in this case (if Alex is really dealing with a livelock in the kernel)...? The deadlock resolver is compiled into the GENERIC kernel on -CURRENT, so I'm assuming it hasn't helped (or perhaps is even part of the problem). I think the best thing to do at this point is to try to get into DDB. Of the schemes I suggested to work around the X11 issue, switching to a virtual console before starting Chromium may work best, since it will continue to use the local X server, etc. An alternate way of handling this: Turn on the VNC X server and use that from a remote place, leaving the console free. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2010-11-13 21:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-13 21:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-11-13 21:00:00 - cleaning the object tree TB --- 2010-11-13 21:00:24 - cvsupping the source tree TB --- 2010-11-13 21:00:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-11-13 21:00:51 - building world TB --- 2010-11-13 21:00:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 21:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 21:00:51 - TARGET=i386 TB --- 2010-11-13 21:00:51 - TARGET_ARCH=i386 TB --- 2010-11-13 21:00:51 - TZ=UTC TB --- 2010-11-13 21:00:51 - __MAKE_CONF=/dev/null TB --- 2010-11-13 21:00:51 - cd /src TB --- 2010-11-13 21:00:51 - /usr/bin/make -B buildworld World build started on Sat Nov 13 21:00:51 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Nov 13 22:46:32 UTC 2010 TB --- 2010-11-13 22:46:32 - generating LINT kernel config TB --- 2010-11-13 22:46:32 - cd /src/sys/i386/conf TB --- 2010-11-13 22:46:32 - /usr/bin/make -B LINT TB --- 2010-11-13 22:46:32 - building LINT kernel TB --- 2010-11-13 22:46:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 22:46:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 22:46:32 - TARGET=i386 TB --- 2010-11-13 22:46:32 - TARGET_ARCH=i386 TB --- 2010-11-13 22:46:32 - TZ=UTC TB --- 2010-11-13 22:46:32 - __MAKE_CONF=/dev/null TB --- 2010-11-13 22:46:32 - cd /src TB --- 2010-11-13 22:46:32 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 13 22:46:32 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Sat Nov 13 23:13:00 UTC 2010 TB --- 2010-11-13 23:13:00 - building GENERIC kernel TB --- 2010-11-13 23:13:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 23:13:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 23:13:00 - TARGET=i386 TB --- 2010-11-13 23:13:00 - TARGET_ARCH=i386 TB --- 2010-11-13 23:13:00 - TZ=UTC TB --- 2010-11-13 23:13:00 - __MAKE_CONF=/dev/null TB --- 2010-11-13 23:13:00 - cd /src TB --- 2010-11-13 23:13:00 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Nov 13 23:13:00 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for GENERIC completed on Sat Nov 13 23:33:39 UTC 2010 TB --- 2010-11-13 23:33:39 - WARNING: no kernel config for GENERIC64 TB --- 2010-11-13 23:33:39 - building PAE kernel TB --- 2010-11-13 23:33:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-13 23:33:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-13 23:33:39 - TARGET=i386 TB --- 2010-11-13 23:33:39 - TARGET_ARCH=i386 TB --- 2010-11-13 23:33:39 - TZ=UTC TB --- 2010-11-13 23:33:39 - __MAKE_CONF=/dev/null TB --- 2010-11-13 23:33:39 - cd /src TB --- 2010-11-13 23:33:39 - /usr/bin/make -B buildkernel KERNCONF=PAE Kernel build for PAE started on Sat Nov 13 23:33:40 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/xdr/xdr_mbuf.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/xdr/xdr_mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-11-14 00:07:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-14 00:07:50 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-14 00:07:50 - cleaning the object tree TB --- 2010-11-14 00:07:53 - cvsupping the source tree TB --- 2010-11-14 00:07:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-14 00:08:07 - building world TB --- 2010-11-14 00:08:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-14 00:08:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-14 00:08:07 - TARGET=powerpc TB --- 2010-11-14 00:08:07 - TARGET_ARCH=powerpc64 TB --- 2010-11-14 00:08:07 - TZ=UTC TB --- 2010-11-14 00:08:07 - __MAKE_CONF=/dev/null TB --- 2010-11-14 00:08:07 - cd /src TB --- 2010-11-14 00:08:07 - /usr/bin/make -B buildworld World build started on Sun Nov 14 00:08:08 UTC 2010 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 [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap === gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk optionlist options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name=config.h system.h coretypes.h tm.h optionlist options.c TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=auto-host.h ansidecl.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-14 00:13:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-14 00:13:09 - ERROR: failed to build world TB --- 2010-11-14 00:13:09 - 205.25 user 57.69 system 318.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
The path is now set for busybox, FreeBSD style
Hi everyone, I've committed the below changes to -HEAD. You can now create and build your own busybox style binary system, completely cross-compiled within the existing Make framework. It isn't as impressive as it sounds though - a lot of the framework is already there from just building crunchgen'ed rescue/sysinstall binaries. There's a few things which should be done. Specifically, being able to build an alternative set of libraries before building the crunchgen target. The base crosscompile system may include support for PAM, Kerberos, ATM/IPX, etc but you may not want your crunch'ed image to have them. To do this right now, you have to disable these features in the main build. That may be OK for some. But just to stress it - I've got a couple of access point images at home running a crunchgen'ed environment under MIPS and besides the obvious binary bloat, it works perfectly well. Besides a cut-down startup framework, the image cross-builds entirely from the base FreeBSD source tree. Let me know if you'd like to give it a shot and I'll put my bsdbox Makefile scripts online to try. Adrian On 5 October 2010 10:36, Adrian Chadd adr...@freebsd.org wrote: Hi, I've broken out the crunchgen logic from src/rescue/rescue into a share/mk file - that way it can be reused in other areas. The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diffhttp://people.freebsd.org/%7Eadrian/crunchgen-mk.diff This bsd.crunchgen.mk file is generic enough to use in my busybox-style thing as well as for src/rescue/rescue/. Comments, feedback, etc welcome! Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
