[head tinderbox] failure on armv6/arm
TB --- 2013-10-27 03:20:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-27 03:20:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-27 03:20:22 - starting HEAD tinderbox run for armv6/arm TB --- 2013-10-27 03:20:22 - cleaning the object tree TB --- 2013-10-27 03:20:22 - /usr/local/bin/svn stat /src TB --- 2013-10-27 03:20:27 - At svn revision 257201 TB --- 2013-10-27 03:20:28 - building world TB --- 2013-10-27 03:20:28 - CROSS_BUILD_TESTING=YES TB --- 2013-10-27 03:20:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-27 03:20:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-27 03:20:28 - SRCCONF=/dev/null TB --- 2013-10-27 03:20:28 - TARGET=arm TB --- 2013-10-27 03:20:28 - TARGET_ARCH=armv6 TB --- 2013-10-27 03:20:28 - TZ=UTC TB --- 2013-10-27 03:20:28 - __MAKE_CONF=/dev/null TB --- 2013-10-27 03:20:28 - cd /src TB --- 2013-10-27 03:20:28 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sun Oct 27 03:20:37 UTC 2013 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 Sun Oct 27 06:24:07 UTC 2013 TB --- 2013-10-27 06:24:07 - generating LINT kernel config TB --- 2013-10-27 06:24:07 - cd /src/sys/arm/conf TB --- 2013-10-27 06:24:07 - /usr/bin/make -B LINT TB --- 2013-10-27 06:24:07 - cd /src/sys/arm/conf TB --- 2013-10-27 06:24:07 - /usr/sbin/config -m LINT TB --- 2013-10-27 06:24:07 - skipping LINT kernel TB --- 2013-10-27 06:24:07 - cd /src/sys/arm/conf TB --- 2013-10-27 06:24:07 - /usr/sbin/config -m AC100 TB --- 2013-10-27 06:24:07 - building AC100 kernel TB --- 2013-10-27 06:24:07 - CROSS_BUILD_TESTING=YES TB --- 2013-10-27 06:24:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-27 06:24:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-27 06:24:07 - SRCCONF=/dev/null TB --- 2013-10-27 06:24:07 - TARGET=arm TB --- 2013-10-27 06:24:07 - TARGET_ARCH=armv6 TB --- 2013-10-27 06:24:07 - TZ=UTC TB --- 2013-10-27 06:24:07 - __MAKE_CONF=/dev/null TB --- 2013-10-27 06:24:07 - cd /src TB --- 2013-10-27 06:24:07 - /usr/bin/make -B buildkernel KERNCONF=AC100 Kernel build for AC100 started on Sun Oct 27 06:24:08 UTC 2013 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 AC100 completed on Sun Oct 27 06:27:10 UTC 2013 TB --- 2013-10-27 06:27:10 - cd /src/sys/arm/conf TB --- 2013-10-27 06:27:10 - /usr/sbin/config -m ARMADAXP TB --- 2013-10-27 06:27:10 - building ARMADAXP kernel TB --- 2013-10-27 06:27:10 - CROSS_BUILD_TESTING=YES TB --- 2013-10-27 06:27:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-27 06:27:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-27 06:27:10 - SRCCONF=/dev/null TB --- 2013-10-27 06:27:10 - TARGET=arm TB --- 2013-10-27 06:27:10 - TARGET_ARCH=armv6 TB --- 2013-10-27 06:27:10 - TZ=UTC TB --- 2013-10-27 06:27:10 - __MAKE_CONF=/dev/null TB --- 2013-10-27 06:27:10 - cd /src TB --- 2013-10-27 06:27:10 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP Kernel build for ARMADAXP started on Sun Oct 27 06:27:10 UTC 2013 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 ARMADAXP completed on Sun Oct 27 06:31:16 UTC 2013 TB --- 2013-10-27 06:31:16 - cd /src/sys/arm/conf TB --- 2013-10-27 06:31:16 - /usr/sbin/config -m ARNDALE TB --- 2013-10-27 06:31:16 - building ARNDALE kernel TB --- 2013-10-27 06:31:16 - CROSS_BUILD_TESTING=YES TB --- 2013-10-27 06:31:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-27 06:31:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-27 06:31:16 - SRCCONF=/dev/null TB --- 2013-10-27 06:31:16 - TARGET=arm TB --- 2013-10-27 06:31:16 - TARGET_ARCH=armv6 TB --- 2013-10-27 06:31:16 - TZ=UTC TB --- 2013-10-27 06:31:16 - __MAKE_CONF=/dev/null TB --- 2013-10-27 06:31:16 - cd /src TB --- 2013-10-27 06:31:16 - /usr/bin/make -B buildkernel KERNCONF=ARNDALE Kernel build for ARNDALE started on Sun Oct 27 06:31:16 UTC 2013 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 ARNDALE completed on Sun Oct 27 06:35:39 UTC 2013 TB --- 2013-10-27 06:35:39 - cd /src/sys/arm/conf TB --- 2013-10-27 06:35:39 - /usr/sbin/config -m ATMEL TB --- 2013-10-27 06:35:39 - skipping ATMEL
Re: 10.0-BETA1 i386 on VirtualBox
Maciej, On Thu, Oct 24, 2013 at 05:16:15PM +0200, Maciej Milewski wrote: M I've encountered problems with installing FreeBSD-10.0-BETA1 i386 under M VirtualBox. M The problem is with setting/changing root password during install M process. After entering password twice there is: M M passwd: pam_chauthtok(): error in service module M M Then there shows pwd_mkdb.core in current directory. M The same VirtualBox machine has no problems with installing M FreeBSD-9.2-RELEASE M M Has anyone any clues? Can you please tell version of VirtualBox and host OS? -- Totus tuus, Glebius. ___ 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 --- 2013-10-27 07:56:01 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-27 07:56:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-27 07:56:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-10-27 07:56:01 - cleaning the object tree TB --- 2013-10-27 07:56:30 - /usr/local/bin/svn stat /src TB --- 2013-10-27 07:56:40 - At svn revision 257201 TB --- 2013-10-27 07:56:41 - building world TB --- 2013-10-27 07:56:41 - CROSS_BUILD_TESTING=YES TB --- 2013-10-27 07:56:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-27 07:56:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-27 07:56:41 - SRCCONF=/dev/null TB --- 2013-10-27 07:56:41 - TARGET=pc98 TB --- 2013-10-27 07:56:41 - TARGET_ARCH=i386 TB --- 2013-10-27 07:56:41 - TZ=UTC TB --- 2013-10-27 07:56:41 - __MAKE_CONF=/dev/null TB --- 2013-10-27 07:56:41 - cd /src TB --- 2013-10-27 07:56:41 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sun Oct 27 07:56:48 UTC 2013 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 [...] CC='cc ' mkdep -f .depend -a-DVISIBILITY_HIDDEN -std=gnu99 /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/absvdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/absvsi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/absvti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/addvdi3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/addvsi3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/addvti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/ashldi3.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ashlti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/ashrdi3.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ashrti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clear_cache.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clzdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clzsi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clzti2.c /src/lib/libcompi! ler_rt/../../contrib/compiler-rt/lib/cmpdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/cmpti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/comparedf2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/comparesf2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ctzdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ctzsi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ctzti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divdc3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/divdi3.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divmoddi4.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divmodsi4.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divsc3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divxc3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/enable_execute_stack.c /src/lib/libcompiler_rt/../! ../contrib/compiler-rt/lib/eprintf.c /src/lib/libcompiler_rt/.! ./../contrib/compiler-rt/lib/ffsdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ffsti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixdfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixdfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixsfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixsfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsdfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsdfsi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsdfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunssfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunssfsi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunssfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsxfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsxfsi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsxfti.c /src/lib/libcompiler_rt/../.! ./contrib/compiler-rt/lib/fixxfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixxfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/floatdidf.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/floatdisf.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/floatdixf.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/floattidf.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/floattisf.c
Re: 10.0-BETA1 i386 on VirtualBox
On 27.10.2013 09:03, Gleb Smirnoff wrote: Maciej, On Thu, Oct 24, 2013 at 05:16:15PM +0200, Maciej Milewski wrote: M I've encountered problems with installing FreeBSD-10.0-BETA1 i386 under M VirtualBox. M The problem is with setting/changing root password during install M process. After entering password twice there is: M M passwd: pam_chauthtok(): error in service module M M Then there shows pwd_mkdb.core in current directory. M The same VirtualBox machine has no problems with installing M FreeBSD-9.2-RELEASE M M Has anyone any clues? Can you please tell version of VirtualBox and host OS? One of them is: FreeBSD 9.2-PRERELEASE #0 r255613: Mon Sep 16 20:25:59 CEST 2013 $ VBoxManage -v 4.2.18_OSEr88780 # pkg_version -vs virtualbox virtualbox-ose-4.2.18_1 = up-to-date with port virtualbox-ose-kmod-4.2.18 = up-to-date with port And the same is with % VBoxManage -v 4.2.18_OSEr88780 Under ArchLinux. -- Pozdrawiam, Maciej Milewski ___ 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
ZFS buggy in CURRENT? Stuck in [zio-io_cv] forever!
I have setup a RAIDZ pool comprised from 4 3TB HDDs. To maintain 4k block alignment, I followed the instructions given on several sites and I'll sketch them here for the protocol. The operating system is 11.0-CURRENT AND 10.0-BETA2. create a GPT partition on each drive and add one whole-covering partition with the option gpart add -t freebsd-zfs -b 1M -l disk0[0-3] ada[3-6] gnop create -S4096 gtp/disk[3-6] Because I added a disk to an existing RAIDZ, I exported the former ZFS pool, then I deleted on each disk the partition and then destroyed the GPT scheme. The former pool had a ZIL and CACHE residing on the same SSD, partioned. I didn't kill or destroy the partitions on that SSD. To align 4k blocks, I also created on the existing gpt/log00 and gpt/cache00 via gnop create -S4096 gpt/log00|gpt/cache00 the NOP overlays. After I created a new pool via zpool create POOL gpt/disk0[0-3].nop log gpt/log00.nop cache gpt/cache00.nop I received a snapshot taken and sent to another storage array, after I the newly created pool didn't show up any signs of illness or corruption. After ~10 hours of receiving the backup, I exported that pool amongst the backup pool, destroyed the appropriate .nop device entries via gnop destroy gpt/disk0[0-3] and the same for cache and log and tried to check via zpool import whether my pool (as well as the backup pool) shows up. And here the nasty mess starts! The zpool import command issued on console is now stuck for hours and can not be interrupted via Ctrl-C! No pool shows up! Hitting Ctrl-T shows a state like ... cmd: zpool 4317 [zio-io_cv]: 7345.34r 0.00 [...] Looking with systat -vm 1 at the trhoughput of the CAM devices I realise that two of the four RAIDZ-comprising drives show activities, having 7000 - 8000 tps and ~ 30 MB/s bandwidth - the other two zero! And the pool is still inactive, the console is stuck. Well, this made my day! At this point, I try to understand what's going wrong and try to recall what I did the last time different when the same procedure on three disks on the same hardware worked for me. Now after 10 hours copy orgy and the need for the working array I start believing that using ZFS is still peppered with too many development-like flaws rendering it risky on FreeBSD. Colleagues working on SOLARIS on ZFS I consulted never saw those stuck-behaviour like I realise this moment. I don not want to repeat the procedure again. There must be a possibility to import the pool - even the backup pool, which is working, untouched by the work, should be able to import - but it doesn't. If I address that pool, while this crap zpool import command is still blocking the console, not willing to die even with killall -9 zpool, I can not import the backup pool via zpool import BACKUP00. The console gets stuck immediately and for the eternity without any notice. Htting Ctrl-T says something like load: 3.59 cmd: zpool 46199 [spa_namespace_lock] 839.18r 0.00u 0.00s 0% 3036k which means I can not even import the backup facility and this means really no fun. signature.asc Description: PGP signature
Re: ZFS buggy in CURRENT? Stuck in [zio-io_cv] forever!
On Sun, 27 Oct 2013 13:40:39 +0100 O. Hartmann ohart...@zedat.fu-berlin.de wrote: I have setup a RAIDZ pool comprised from 4 3TB HDDs. To maintain 4k block alignment, I followed the instructions given on several sites and I'll sketch them here for the protocol. The operating system is 11.0-CURRENT AND 10.0-BETA2. create a GPT partition on each drive and add one whole-covering partition with the option gpart add -t freebsd-zfs -b 1M -l disk0[0-3] ada[3-6] gnop create -S4096 gtp/disk[3-6] Because I added a disk to an existing RAIDZ, I exported the former ZFS pool, then I deleted on each disk the partition and then destroyed the GPT scheme. The former pool had a ZIL and CACHE residing on the same SSD, partioned. I didn't kill or destroy the partitions on that SSD. To align 4k blocks, I also created on the existing gpt/log00 and gpt/cache00 via gnop create -S4096 gpt/log00|gpt/cache00 the NOP overlays. After I created a new pool via zpool create POOL gpt/disk0[0-3].nop log gpt/log00.nop cache gpt/cache00.nop It is, of course, a zpool create POOL raidz ... I received a snapshot taken and sent to another storage array, after I the newly created pool didn't show up any signs of illness or corruption. After ~10 hours of receiving the backup, I exported that pool amongst the backup pool, destroyed the appropriate .nop device entries via gnop destroy gpt/disk0[0-3] and the same for cache and log and tried to check via zpool import whether my pool (as well as the backup pool) shows up. And here the nasty mess starts! The zpool import command issued on console is now stuck for hours and can not be interrupted via Ctrl-C! No pool shows up! Hitting Ctrl-T shows a state like ... cmd: zpool 4317 [zio-io_cv]: 7345.34r 0.00 [...] Looking with systat -vm 1 at the trhoughput of the CAM devices I realise that two of the four RAIDZ-comprising drives show activities, having 7000 - 8000 tps and ~ 30 MB/s bandwidth - the other two zero! And the pool is still inactive, the console is stuck. Well, this made my day! At this point, I try to understand what's going wrong and try to recall what I did the last time different when the same procedure on three disks on the same hardware worked for me. Now after 10 hours copy orgy and the need for the working array I start believing that using ZFS is still peppered with too many development-like flaws rendering it risky on FreeBSD. Colleagues working on SOLARIS on ZFS I consulted never saw those stuck-behaviour like I realise this moment. I don not want to repeat the procedure again. There must be a possibility to import the pool - even the backup pool, which is working, untouched by the work, should be able to import - but it doesn't. If I address that pool, while this crap zpool import command is still blocking the console, not willing to die even with killall -9 zpool, I can not import the backup pool via zpool import BACKUP00. The console gets stuck immediately and for the eternity without any notice. Htting Ctrl-T says something like load: 3.59 cmd: zpool 46199 [spa_namespace_lock] 839.18r 0.00u 0.00s 0% 3036k which means I can not even import the backup facility and this means really no fun. signature.asc Description: PGP signature
Re: Centrino Wireless N2230 support
Hello Cedric, Am 26.10.2013 10:56, schrieb c...@cgross.info: You must get and build net80211 from -HEAD also. It's why you have this kind of compile error. Thanks, this was exactly my miss. With net80211 from -HEAD it built. I first tried IWL (https://github.com/KreizIT/freebsd-iwl) with FreeBSD 9.2-RELEASE. When I try to load the module with kldload if_iwl the kernel panics: Unread portion of the kernel message buffer: iwl0: Intel Centrino Wireless-N 2230 mem 0xf150-0xf1501fff irq 17 at device 0.0 on pci2 iwl0: iwl_read_eeprom_ht40: no entry for channel 1 iwl0: iwl_read_eeprom_ht40: no entry for channel 2 iwl0: iwl_read_eeprom_ht40: no entry for channel 3 iwl0: iwl_read_eeprom_ht40: no entry for channel 4 iwl0: iwl_read_eeprom_ht40: no entry for channel 5 iwl0: iwl_read_eeprom_ht40: no entry for channel 6 iwl0: iwl_read_eeprom_ht40: no entry for channel 7 panic: ieee80211_get_ratetable: no rate table for channel; freq 0 flags 0x0 cpuid = 3 KDB: stack backtrace: #0 0x80947986 at kdb_backtrace+0x66 #1 0x8090d9ae at panic+0x1ce #2 0x80a1399e at ieee80211_get_ratetable+0x10e #3 0x809eb3a5 at ieee80211_media_init+0x355 #4 0x809eb69e at ieee80211_ifattach+0xae #5 0x81864914 at iwl_attach+0xbd4 #6 0x8186d360 at iwl_pci_attach+0x2f0 #7 0x809405dc at device_attach+0xcc #8 0x8064a0ca at pci_driver_added+0xda #9 0x8093e765 at devclass_driver_added+0x75 #10 0x8093f2a3 at devclass_add_driver+0x103 #11 0x808f80c8 at module_register_init+0xa8 #12 0x808f004e at linker_load_module+0x85e #13 0x808f0688 at kern_kldload+0xb8 #14 0x808f08a4 at sys_kldload+0x84 #15 0x80cf187a at amd64_syscall+0x5ea #16 0x80cdbff7 at Xfast_syscall+0xf7 Any ideas? Kind regards, Matthias ___ 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: [PATCH] contrib/groff Queisce -Wdangling else
On Sat, 2013-10-26 at 20:22 -0400, Eitan Adler wrote: On Sat, Oct 26, 2013 at 11:04 AM, Sean Bruno sean_br...@yahoo.com wrote: This adds proper braces to clear Clang warnings about dangling else statements in groff. There is no(intended) functional change. For contributed code why not just disable warnings? Fixing code is good but doing so in our repository instead of upstream doesn't help as much. I believe very strongly that the people who construct compilers know C/C ++ far better than I do, so warnings are their note to me that I'm doing it wrong. Disabling warnings is global for a section of the tree (e.g. groff/roff). I can't (easily) isolate the warnings individually, so modifications to the code after I disable the warnings will get excluded as well, effectively opening the project to crappy code that breaks things (if the warnings are causing bugs). For this specific code (groff), it switched to gpl v3 in 2009, so we won't be doing any more code drops into our tree: Revision 1.5 - (view) (download) (annotate) - [select for diffs] Sun Jan 4 14:50:51 2009 UTC (4 years, 9 months ago) by wl Branch: MAIN Changes since 1.4: +3 -3 lines Diff to previous 1.4 * */*: Update GPL2 to GPL3. Therefore, if someone isn't going to rewrite the implementations, its up to us to maintain the code we have. sean Warnings are meaningful. FreeBSD Clusteradm/Developer signature.asc Description: This is a digitally signed message part
Re: ZFS buggy in CURRENT? Stuck in [zio-io_cv] forever!
- Original Message - From: O. Hartmann ohart...@zedat.fu-berlin.de I have setup a RAIDZ pool comprised from 4 3TB HDDs. To maintain 4k block alignment, I followed the instructions given on several sites and I'll sketch them here for the protocol. The operating system is 11.0-CURRENT AND 10.0-BETA2. create a GPT partition on each drive and add one whole-covering partition with the option gpart add -t freebsd-zfs -b 1M -l disk0[0-3] ada[3-6] gnop create -S4096 gtp/disk[3-6] Because I added a disk to an existing RAIDZ, I exported the former ZFS pool, then I deleted on each disk the partition and then destroyed the GPT scheme. The former pool had a ZIL and CACHE residing on the same SSD, partioned. I didn't kill or destroy the partitions on that SSD. To align 4k blocks, I also created on the existing gpt/log00 and gpt/cache00 via gnop create -S4096 gpt/log00|gpt/cache00 the NOP overlays. After I created a new pool via zpool create POOL gpt/disk0[0-3].nop log gpt/log00.nop cache gpt/cache00.nop You don't need any of the nop hax in 10 or 11 any more as it has proper sector size detection. The caviate for this is when you have a disk which adervtises 512b sectors but is 4k and we dont have a 4k quirk in the kernel for it yet. If you anyone comes across a case of this feel free to drop me the details from camcontrol identify|inquiry device If due to this you still need to use the gnop hack then you only need to apply it to 1 device as the zpool create uses the largest ashift from the disks. I would then as the very first step export and import as at this point there is much less data on the devices to scan through, not that this should be needed but... I received a snapshot taken and sent to another storage array, after I the newly created pool didn't show up any signs of illness or corruption. After ~10 hours of receiving the backup, I exported that pool amongst the backup pool, destroyed the appropriate .nop device entries via gnop destroy gpt/disk0[0-3] and the same for cache and log and tried to check via zpool import whether my pool (as well as the backup pool) shows up. And here the nasty mess starts! The zpool import command issued on console is now stuck for hours and can not be interrupted via Ctrl-C! No pool shows up! Hitting Ctrl-T shows a state like ... cmd: zpool 4317 [zio-io_cv]: 7345.34r 0.00 [...] Looking with systat -vm 1 at the trhoughput of the CAM devices I realise that two of the four RAIDZ-comprising drives show activities, having 7000 - 8000 tps and ~ 30 MB/s bandwidth - the other two zero! And the pool is still inactive, the console is stuck. Well, this made my day! At this point, I try to understand what's going wrong and try to recall what I did the last time different when the same procedure on three disks on the same hardware worked for me. Now after 10 hours copy orgy and the need for the working array I start believing that using ZFS is still peppered with too many development-like flaws rendering it risky on FreeBSD. Colleagues working on SOLARIS on ZFS I consulted never saw those stuck-behaviour like I realise this moment. While we only run 8.3-RELEASE currently, as we've decided to skip 9.X and move straight to 10 once we've tested, we've found ZFS is not only very stable but it now become critical to the way we run things. I don not want to repeat the procedure again. There must be a possibility to import the pool - even the backup pool, which is working, untouched by the work, should be able to import - but it doesn't. If I address that pool, while this crap zpool import command is still blocking the console, not willing to die even with killall -9 zpool, I can not import the backup pool via zpool import BACKUP00. The console gets stuck immediately and for the eternity without any notice. Htting Ctrl-T says something like load: 3.59 cmd: zpool 46199 [spa_namespace_lock] 839.18r 0.00u 0.00s 0% 3036k which means I can not even import the backup facility and this means really no fun. I'm not sure there's enough information here to determine where any issue may lie, but as a guess it could be that ZFS is having issues locating the one change devices and is scanning the entire disk to try and determine that. This would explain the IO on the one device but not the others. Did you per-chance have one of the disks in use for something else and hence it may have old label information in it that wasn't cleaned down? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk.
Fwd: Re: ZFS buggy in CURRENT? Stuck in [zio-io_cv] forever!
Forgot to include the list in reply. -- Forwarded message -- From: Freddie Cash fjwc...@gmail.com Date: Oct 27, 2013 10:36 AM Subject: Re: ZFS buggy in CURRENT? Stuck in [zio-io_cv] forever! To: O. Hartmann ohart...@zedat.fu-berlin.de Cc: Did your recv complete before you exported the pool? If not, then the import will hang until it has deleted three hidden clone dataset for the aborted receive. Once all the blocks are freed successfully, then the import will complete and the pool well be usable again. ___ 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 --- 2013-10-27 19:14:37 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-27 19:14:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-27 19:14:37 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-10-27 19:14:37 - cleaning the object tree TB --- 2013-10-27 19:15:07 - /usr/local/bin/svn stat /src TB --- 2013-10-27 19:15:38 - At svn revision 257209 TB --- 2013-10-27 19:15:39 - building world TB --- 2013-10-27 19:15:39 - CROSS_BUILD_TESTING=YES TB --- 2013-10-27 19:15:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-27 19:15:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-27 19:15:39 - SRCCONF=/dev/null TB --- 2013-10-27 19:15:39 - TARGET=pc98 TB --- 2013-10-27 19:15:39 - TARGET_ARCH=i386 TB --- 2013-10-27 19:15:39 - TZ=UTC TB --- 2013-10-27 19:15:39 - __MAKE_CONF=/dev/null TB --- 2013-10-27 19:15:39 - cd /src TB --- 2013-10-27 19:15:39 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sun Oct 27 19:15:47 UTC 2013 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 [...] CC='cc ' mkdep -f .depend -a-DVISIBILITY_HIDDEN -std=gnu99 /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/absvdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/absvsi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/absvti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/addvdi3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/addvsi3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/addvti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/ashldi3.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ashlti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/ashrdi3.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ashrti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clear_cache.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clzdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clzsi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/clzti2.c /src/lib/libcompi! ler_rt/../../contrib/compiler-rt/lib/cmpdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/cmpti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/comparedf2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/comparesf2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ctzdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ctzsi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ctzti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divdc3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/divdi3.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divmoddi4.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divmodsi4.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divsc3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divti3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/divxc3.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/enable_execute_stack.c /src/lib/libcompiler_rt/../! ../contrib/compiler-rt/lib/eprintf.c /src/lib/libcompiler_rt/.! ./../contrib/compiler-rt/lib/ffsdi2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/ffsti2.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixdfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixdfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixsfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixsfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsdfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsdfsi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsdfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunssfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunssfsi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunssfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsxfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsxfsi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixunsxfti.c /src/lib/libcompiler_rt/../.! ./contrib/compiler-rt/lib/fixxfdi.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/fixxfti.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/floatdidf.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/floatdisf.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/i386/floatdixf.S /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/floattidf.c /src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/floattisf.c
Re: [PATCH] contrib/groff Queisce -Wdangling else [updated]
On Sat, 2013-10-26 at 11:04 -0400, Sean Bruno wrote: This adds proper braces to clear Clang warnings about dangling else statements in groff. There is no(intended) functional change. http://people.freebsd.org/~sbruno/groff_dangling_else.txt sean I've updated the patch at this link and only put in the needed parenthesis to quiesce the clang warnings. Code binary sizes appear identical after these changes. Thanks to Jiles for pointing me at unintended code changes. sean signature.asc Description: This is a digitally signed message part
Re: newcons comming
On Fri, Oct 25, 2013 at 03:18:47PM +0300, Aleksandr Rybalko wrote: Hello fellow hackers! I finally reach the point when I can work with newcons instead of syscons on my laptop. Yes, I know it still buggy and have a lot of style(9) problems. But we really have to get it into HEAD and 10.0 to enable shiny new Xorg features, drivers, etc. So I ask everyone to look hard into that[1] and tell me your opinion. I expect a lot of opinions, since it have to affect almost all good guys, as result I have to ask to split bug reports into two parts: 1. Should be done before merge to 10.0; 2. Can be done later. If it possible, please do it(review - report) ASAP. Could you please port at least either creator(4) or machfb(4) to newcons before it even hits head so we don't have the same situation as with syscons again where we need to make square pegs fit into round holes? My main concerns in this regard are: o Making these drivers work as low-level console in the syscons sense so they already work for printing the Copyright notice of the kernel. The problem here is that the respective chips don't necessarily come up with the frame buffer mapped and we can't do that on our own at that point with the VM not up, yet. So all access has to be done via bus_space_*(9) and specially crafted bus tags and handles. In short: Except for some specific model and firmware combinations, in general the generic OFW frame buffer approach doesn't work here, that's why these drivers exist in the first place. o For coexistence of f. e. machfb(4) with ofwfb.c, allow some probing of drivers in the BUS_PROBE_GENERIC/BUS_PROBE_DEFAULT etc. manner. The crucial point here is that in case a more specific driver is willing to attach to a certain device, a generic driver must not touch the hardware in any way. It seems that vd_priority is too late in the game for that requirement. With syscons, this is achievable by letting the generic driver call vid_configure(VIO_PROBE_ONLY) and then check whether another driver has taken the device. o Using hardware acceleration for drawing characters and the mouse pointer, i. e. using a hardware cursor. Employing the respective chips as dumb frame buffers instead is just dog slow. Currently, I don't see how a hardware cursor could be hooked up to newcons. The current putc code in these drivers _might_ be suitable for implementing bitbltchr methods. Apart from that these chips also can do simple bitblt etc. of course. o Using the 12 x 22 gallant font. o Allowing Xorg to map the frame buffer but additionally also other register banks as needed through newcons. With syscons, a driver can provide a mmap method for that (see machfb(4). I currently don't see how to do that with the newcons infrastructure. An alternative might be to make Xorg/ libpciaccess aware of newcons and go through a /dev/fdX in that case. Still, I don't see how to currently do that for resources besides the actual frame buffer with existing fdc.c. I'm also not sure whether the latter is the appropriate route to go in the first place given that besides mmap'ing from userland, newcons'ified creator(4) and machfb(4) still should be used directly. In any case, for creator(4) Xorg expects a /dev/fdX anyway. o Allowing late attachment in case the primary console is the serial one, another graphics chip etc. during regular device attachment when everything needed (mainly the VM) to bring the frame buffer fully online on our own is available. Is that what vt_allocate() is for? Marius ___ 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
HELP WANTED: Figure out why svnlite build is sometimes not reproducible
Hi all, Doing freebsd-update builds, I've now had two instances where /usr/bin/svnlite has built inexplicably differently -- changes scattered all over the binary. This is a problem for freebsd-update because it means that at some point in the future the builds may not be able to correctly identify if that binary needs to be distributed as part of a security update. The svn* binaries had build date+time stamps in them until I nuked them in r257129, but those are cleanly self-contained -- this is something else building differently. Unfortunately despite the freebsd-update builds running into this, I haven't been able to reproduce it myself and so I can't track down what is causing this. If anyone can provide assistance with this, it would be very gratefully received. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ 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: HELP WANTED: Figure out why svnlite build is sometimes not reproducible
On 10/27/13 14:52, Erik Cederstrand wrote: Den 27/10/2013 kl. 22.03 skrev Colin Percival cperc...@freebsd.org: Doing freebsd-update builds, I've now had two instances where /usr/bin/svnlite has built inexplicably differently -- changes scattered all over the binary. Which kind of changes? Are you aware of the -D flag to ar(1) (wipes timestamps in archives)? Are you always using the same SRCDIR/DESTDIR (this affects the __FILE__ macro)? Same DEBUG_FLAGS? Changes in lots of non-7-bit-ASCII bits all over the file. I'm guessing it's executable code. Yes, aware of -D flag. That's a red herring since this isn't an archive; and all the other binaries are fine. Yes, all the build context is the same -- this is happening inside a chroot with the same build script running every time. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ 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: HELP WANTED: Figure out why svnlite build is sometimes not reproducible
Hi Colin, Den 27/10/2013 kl. 22.03 skrev Colin Percival cperc...@freebsd.org: Hi all, Doing freebsd-update builds, I've now had two instances where /usr/bin/svnlite has built inexplicably differently -- changes scattered all over the binary. Which kind of changes? Are you aware of the -D flag to ar(1) (wipes timestamps in archives)? Are you always using the same SRCDIR/DESTDIR (this affects the __FILE__ macro)? Same DEBUG_FLAGS? Erik ___ 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: ZFS buggy in CURRENT? Stuck in [zio-io_cv] forever!
On Sun, 27 Oct 2013 16:32:13 - Steven Hartland kill...@multiplay.co.uk wrote: - Original Message - From: O. Hartmann ohart...@zedat.fu-berlin.de I have setup a RAIDZ pool comprised from 4 3TB HDDs. To maintain 4k block alignment, I followed the instructions given on several sites and I'll sketch them here for the protocol. The operating system is 11.0-CURRENT AND 10.0-BETA2. create a GPT partition on each drive and add one whole-covering partition with the option gpart add -t freebsd-zfs -b 1M -l disk0[0-3] ada[3-6] gnop create -S4096 gtp/disk[3-6] Because I added a disk to an existing RAIDZ, I exported the former ZFS pool, then I deleted on each disk the partition and then destroyed the GPT scheme. The former pool had a ZIL and CACHE residing on the same SSD, partioned. I didn't kill or destroy the partitions on that SSD. To align 4k blocks, I also created on the existing gpt/log00 and gpt/cache00 via gnop create -S4096 gpt/log00|gpt/cache00 the NOP overlays. After I created a new pool via zpool create POOL gpt/disk0[0-3].nop log gpt/log00.nop cache gpt/cache00.nop You don't need any of the nop hax in 10 or 11 any more as it has proper sector size detection. The caviate for this is when you have a disk which adervtises 512b sectors but is 4k and we dont have a 4k quirk in the kernel for it yet. Well, this is news to me. If you anyone comes across a case of this feel free to drop me the details from camcontrol identify|inquiry device camcontrol identify says this (serial numbers skipped): ada3: cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 5860533168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 5400 Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standbyyes no write-read-verify no no unload yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 5860533168/5860533168 HPA - Security no ada4/ada5/ada6: cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 5860533168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standbyyes no write-read-verify no no unload no no free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 5860533168/5860533168 HPA - Security no If due to this you still need to use the gnop hack then you only need to apply it to 1 device as the zpool create uses the largest ashift from the disks. This is also new and not obviously reported/documented well. I would then as the very first step export and import as at this point there is much less data on the devices to scan through, not that this should be needed but... I performed the task again. The pool is not destroyed, as I can not import it anymore. I do so delete all the partitions and then destroying the GPT scheme and recreating it as well as the partions. After the receive finished after 10 hours, I exported the backup pool and the newly created pool. Now I'm trying to import the new pool again - and I'm stuck again. This crap is stuck, really stuck. I can not - kill the process - shutdown the server(!) Yes, shutdown the
Re: HELP WANTED: Figure out why svnlite build is sometimes not reproducible
Colin Percival wrote this message on Sun, Oct 27, 2013 at 14:03 -0700: Doing freebsd-update builds, I've now had two instances where /usr/bin/svnlite has built inexplicably differently -- changes scattered all over the binary. This is a problem for freebsd-update because it means that at some point in the future the builds may not be able to correctly identify if that binary needs to be distributed as part of a security update. The svn* binaries had build date+time stamps in them until I nuked them in r257129, but those are cleanly self-contained -- this is something else building differently. Unfortunately despite the freebsd-update builds running into this, I haven't been able to reproduce it myself and so I can't track down what is causing this. If anyone can provide assistance with this, it would be very gratefully received. Can you post the binaries somewhere so we can take a look at them? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
