Re: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
Doug, Haven't tried with different GPT parameters so I guess I could try that. It's just odd since that same guide worked for me without a hitch on my desktop machine. I'll try that as well as dd'ing the drive completely. Thanks, Chris On Tue, Feb 16, 2010 at 10:36 PM, Doug Poland d...@polands.org wrote: On 2010-02-16 20:51, Chris wrote: On Tue, Feb 16, 2010 at 9:49 PM, Chrisbehrnetwo...@gmail.com wrote: Scot, If you're following the wiki, then you're using GPT partitions and geom labels, yes? Have you, by chance, tried the install with different GPT partition sizes, indexes, or labels? The reason I ask is I recently had an 8.0-STABLE box on which I installed ZFS root on RAIDZ1, then I decided to change my GPT and re-install. I could not get it to boot from ZFS until I dd'd *all* the drives (completely, not just the first few MB), and started the entire installation from scratch. -- Regards, Doug ___ 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
lang/perl5.10 broken
Not sure if this is ARM related or not. `sh cflags optimize='-O -pipe -mcpu=arm9' opmini.o` -DPIC -fPIC -DPERL_EXTERNAL_GLOB opmini.c CCCMD = cc -DPERL_CORE -c -DAPPLLIB_EXP=/usr/local/lib/perl5/5.10.1/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -O -pipe -mcpu=arm9 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat `sh cflags optimize='-O -pipe -mcpu=arm9' perlmini.o` -DPIC -fPIC -DPERL_IS_MINIPERL perlmini.c CCCMD = cc -DPERL_CORE -c -DAPPLLIB_EXP=/usr/local/lib/perl5/5.10.1/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -O -pipe -mcpu=arm9 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1 cc -Wl,-E -fstack-protector -L/usr/local/lib -o miniperlgv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o miniperlmain.o opmini.o perlmini.o -lm -lcrypt -lutil LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1 ./miniperl -w -Ilib -MExporter -e '?' || make minitest cp ext/re/re.pm lib/re.pm LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1 ./miniperl -Ilib make_patchnum.pl *** Signal 11 Stop in /usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1. *** Error code 1 (ignored) You may see some irrelevant test failures if you have been unable to build lib/Config.pm, lib/lib.pm or the Unicode data files. cd t (rm -f perl; /bin/ln -s ../miniperl perl) LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1 ./perl TEST -minitest base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t uni/*.t /dev/tty *** Signal 11 (ignored) LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1 ./miniperl -Ilib autodoc.pl *** Signal 11 Stop in /usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1. *** Error code 1 Stop in /usr/ports/lang/perl5.10. *** Error code 1 Stop in /usr/ports/lang/perl5.10. 11062.000u 1053.000s 4:22:49.31 76.8% 717+-46k 198+25986io 1405pf+0w Exit 1 [99]Please.tell.me.who.am.I# gdb /usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1/miniperl /usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1/t/miniperl.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as arm-marcel-freebsd...(no debugging symbols found)... Core was generated by `miniperl'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000f6eb4 in Perl_new_collate () (gdb) bt #0 0x000f6eb4 in Perl_new_collate () #1 0x000f7904 in Perl_init_i18nl10n () #2 0x0011e618 in perl_construct () #3 0x00103e10 in main () (gdb) -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
Ok, went back to my 8.0-RELEASE memstick image and after playing with the GPT settings a little and dd'ing all zeros to the disk first, I get a little farther this time. I'm seeing the following: - BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS 631kB/1832448kB available memory FreeBSD/i386 bootstrap loader, Revision 1.0 (root@, Wed Feb 17 10:27:40 UTC 2010) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x8924d8 - And that's as far as it gets. Per the handbook, that appears to be stuck somewhere between boot2 and /boot/loader. To me, it looks like it's having a problem loading the kernel. As far as my suspicion of the BIOS not correctly reporting the drives, it looks to me like the bootloader is seeing them so maybe that can be ruled out. I'm glad to see it get farther this time but this is still weird. Any ideas on this one? Thanks, Chris On Wed, Feb 17, 2010 at 8:28 AM, Chris behrnetwo...@gmail.com wrote: Doug, Haven't tried with different GPT parameters so I guess I could try that. It's just odd since that same guide worked for me without a hitch on my desktop machine. I'll try that as well as dd'ing the drive completely. Thanks, Chris On Tue, Feb 16, 2010 at 10:36 PM, Doug Poland d...@polands.org wrote: On 2010-02-16 20:51, Chris wrote: On Tue, Feb 16, 2010 at 9:49 PM, Chrisbehrnetwo...@gmail.com wrote: Scot, If you're following the wiki, then you're using GPT partitions and geom labels, yes? Have you, by chance, tried the install with different GPT partition sizes, indexes, or labels? The reason I ask is I recently had an 8.0-STABLE box on which I installed ZFS root on RAIDZ1, then I decided to change my GPT and re-install. I could not get it to boot from ZFS until I dd'd *all* the drives (completely, not just the first few MB), and started the entire installation from scratch. -- Regards, Doug ___ 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: lang/perl5.10 broken
In message: 20100217152557.gw43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : Not sure if this is ARM related or not. ... : *** Signal 11 Silly question: do you have enough swap space enabled? Warner ___ 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
ATA_CAM-ed mvsata(4) on OpenRD-client
Hi mav! I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to make mvsata(4) ATA_CAM, like following: based on sys/arm/conf/DB-88F6XXX - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # SATA #device ata #device atadisk device atacore device atamvsata options ATA_CAM - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But I got following panic, my I help you? In this time, I attached no devices to SATA/eSATA port. - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sata0: Marvell Integrated SATA Controller at mem 0xf108-0xf1085fff irq 21 on mbus0 sata0: [MPSAFE] sata0: [ITHREAD] ata0: Marvell Integrated SATA Channel on sata0 ata0: [MPSAFE] ata0: [ITHREAD] ata1: Marvell Integrated SATA Channel on sata0 ata1: [MPSAFE] ata1: [ITHREAD] spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long panic: spin lock held too long KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at 0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror r15]! db - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So I tried to get following information: - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - db show locks exclusive sleep mutex Giant (Giant) r = 0 (0xc0be3ad4) locked @ /usr/src/sys/kern/kern_module.c:117 db show alllocks Process 0 (kernel) thread 0xc0be1fa0 (10) exclusive sleep mutex Giant (Giant) r = 0 (0xc0be3ad4) locked @ /usr/src/sys/kern/kern_module.c:117 db show lockedvnods Locked vnodes db show pcpu cpuid= 0 dynamic pcpu= 0x17fc00 curthread= 0xc0be1fa0: pid 0 swapper curpcb = 0xc0d62ef8 fpcurthread = none idlethread = 0xc357bd80: pid 10 idle spin locks held: db bt Tracing pid 0 tid 10 td 0xc0be1fa0 kdb_enter() at 0xc09dcb18 = kdb_enter+0x10 scp=0xc09dcb18 rlv=0xc09b2cf0 (0xc09b2cf0 = panic+0xcc) rsp=0xc0d62c1c rfp=0xc0d62c30 r4=0x0100 panic() at 0xc09b2c38 = panic+0x14 scp=0xc09b2c38 rlv=0xc09a6fb8 (0xc09a6fb8 = _thread_lock_flags+0x170) rsp=0xc0d62c44 rfp=0xc0d62c8c _thread_lock_flags() at 0xc09a6e58 = _thread_lock_flags+0x10 scp=0xc09a6e58 rlv=0xc09e9e98 (0xc09e9e98 = turnstile_claim+0x174) rsp=0xc0d62c90 rfp=0xc0d62cac r10=0xc3556000 r9=0x r8=0xc3556000 r7=0x0044 r6=0xc3556000 r5=0xc3766680 r4=0xc0b644c0 turnstile_claim() at 0xc09e9e40 = turnstile_claim+0x11c scp=0xc09e9e40 rlv=0xc09ea17c (0xc09ea17c = turnstile_wait+0x208) rsp=0xc0d62cb0 rfp=0xc0d62cdc r7=0xc0be1fa0 r6=0xc0be8e40 r5=0xc0b644c0 r4=0x turnstile_wait() at 0xc09e9f84 = turnstile_wait+0x10 scp=0xc09e9f84 rlv=0xc09a6b30 (0xc09a6b30 = _mtx_lock_sleep+0x11c) rsp=0xc0d62ce0 rfp=0xc0d62d10 r10=0xc0b47100 r9=0x r8=0x r7=0x r6=0xc0be1fa0 r5=0xc3556000 r4=0xc35dd974 _mtx_lock_sleep() at 0xc09a6a24 = _mtx_lock_sleep+0x10 scp=0xc09a6a24 rlv=0xc09a6c0c (0xc09a6c0c = _mtx_lock_flags+0x7c) rsp=0xc0d62d14 rfp=0xc0d62d3c r10=0xc0d62d70 r9=0xc09039a8 r8=0x r7=0x0851 r6=0xc0b47100 r5=0x r4=0xc35dd974 _mtx_lock_flags() at 0xc09a6ba0 = _mtx_lock_flags+0x10 scp=0xc09a6ba0 rlv=0xc0903fac (0xc0903fac = xpt_sim_opened+0x17c) rsp=0xc0d62d40 rfp=0xc0d62d68 r8=0xc0bde8f0 r7=0xc090d4a4 r6=0xc3765e00 r5=0xc0b47100 r4=0xc3766240 xpt_sim_opened() at 0xc0903f3c = xpt_sim_opened+0x10c scp=0xc0903f3c rlv=0xc0904068 (0xc0904068 = xpt_sim_opened+0x238) rsp=0xc0d62d6c rfp=0xc0d62d88 r10=0xc0bde904 r9=0xc0b47100 r8=0x r7=0xc090d4a4 r6=0x0080 r5=0x r4=0x0001 xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218 scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0) rsp=0xc0d62d8c rfp=0xc0d62e34 xpt_register_async() at 0xc0905880 = xpt_register_async+0x10 scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198) rsp=0xc0d62e38 rfp=0xc0d62e44 r10=0x r9=0x r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0 r4=0x001c ata_get_xport() at 0xc090d474 = ata_get_xport+0x2188 scp=0xc090d474 rlv=0xc0900868 (0xc0900868 = periphdriver_init+0x60) rsp=0xc0d62e48 rfp=0xc0d62e58 periphdriver_init() at 0xc0900818 = periphdriver_init+0x10 scp=0xc0900818 rlv=0xc0904584 (0xc0904584 = xpt_alloc_ccb+0x6c) rsp=0xc0d62e5c rfp=0xc0d62e74 r4=0x xpt_alloc_ccb() at 0xc0904554 = xpt_alloc_ccb+0x3c scp=0xc0904554 rlv=0xc09d2d9c (0xc09d2d9c = vaccess_acl_posix1e+0x628) rsp=0xc0d62e78 rfp=0xc0d62ee0 r4=0x vaccess_acl_posix1e() at 0xc09d2d44 = vaccess_acl_posix1e+0x5d0 scp=0xc09d2d44 rlv=0xc097b0ec (0xc097b0ec = mi_startup+0xdc) rsp=0xc0d62ee4 rfp=0xc0d62ef4
Re: lang/perl5.10 broken
On Wed, Feb 17, 2010 at 10:01:13AM -0700, M. Warner Losh wrote: In message: 20100217152557.gw43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : Not sure if this is ARM related or not. ... : *** Signal 11 Silly question: do you have enough swap space enabled? First try was with 128M on internal SD of which usually just about 10M is used during compiler runs and the second was with 1G on external USB SD reader, but just because of speed with internal. I also saw no kernel message that the system was out of space. I'm currently trying to compile perl5.8, but it takes some time. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
On Wed, Feb 17, 2010 at 7:46 AM, Chris behrnetwo...@gmail.com wrote: Ok, went back to my 8.0-RELEASE memstick image and after playing with the GPT settings a little and dd'ing all zeros to the disk first, I get a little farther this time. I'm seeing the following: - BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS 631kB/1832448kB available memory FreeBSD/i386 bootstrap loader, Revision 1.0 (root@, Wed Feb 17 10:27:40 UTC 2010) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x8924d8 - And that's as far as it gets. Per the handbook, that appears to be stuck somewhere between boot2 and /boot/loader. To me, it looks like it's having a problem loading the kernel. As far as my suspicion of the BIOS not correctly reporting the drives, it looks to me like the bootloader is seeing them so maybe that can be ruled out. I'm glad to see it get farther this time but this is still weird. Any ideas on this one? IIRC the 8.0-RELEASE gptzfsboot/loader lacked some bugfixes. Try using gptzfsboot and zfsloader from -STABLE. Matt ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
Shouldn't those bug fixes have been included in CURRENT? If so, my original post shows the problems there. I've also tried using the 8.0-STABLE snapshot dvd1 and got the same errors I got when using CURRENT. Again, not sure why this worked on my desktop box and is failing on the laptop. I'll try copying over gptzfsboot and zfsloader from my 8.0-STABLE machine. On Wed, Feb 17, 2010 at 1:15 PM, Matt Reimer mattjrei...@gmail.com wrote: On Wed, Feb 17, 2010 at 7:46 AM, Chris behrnetwo...@gmail.com wrote: Ok, went back to my 8.0-RELEASE memstick image and after playing with the GPT settings a little and dd'ing all zeros to the disk first, I get a little farther this time. I'm seeing the following: - BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS 631kB/1832448kB available memory FreeBSD/i386 bootstrap loader, Revision 1.0 (root@, Wed Feb 17 10:27:40 UTC 2010) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x8924d8 - And that's as far as it gets. Per the handbook, that appears to be stuck somewhere between boot2 and /boot/loader. To me, it looks like it's having a problem loading the kernel. As far as my suspicion of the BIOS not correctly reporting the drives, it looks to me like the bootloader is seeing them so maybe that can be ruled out. I'm glad to see it get farther this time but this is still weird. Any ideas on this one? IIRC the 8.0-RELEASE gptzfsboot/loader lacked some bugfixes. Try using gptzfsboot and zfsloader from -STABLE. Matt ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
On Wed, Feb 17, 2010 at 10:18 AM, Chris behrnetwo...@gmail.com wrote: Shouldn't those bug fixes have been included in CURRENT? If so, my original post shows the problems there. I've also tried using the 8.0-STABLE snapshot dvd1 and got the same errors I got when using CURRENT. Again, not sure why this worked on my desktop box and is failing on the laptop. I'll try copying over gptzfsboot and zfsloader from my 8.0-STABLE machine. My bad, I wasn't reading carefully. -CURRENT has fixes for all the problems I know of. Matt ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
Hello Chris, Scott Current I use gptzfsboot on my AMD64 (current) machine all the time and also on my laptop. I am not sure if this will cause the problem you are seeing but I know I ran into a lot of trouble depending on what type of pool I was creating. I believe this is correct, and if I am not than I apologise in advance, but If you are trying to boot off a linear type pool (A single disk or a mirror) your bootable filing system has to be a zfs filing system beneath the root pool (IE: zroot/boot). If you are trying to boot off a zraid pool, your bootable filing system must be the root filing system of the pool (IE: zroot) You must also include the appropriate declaration in the /boot/loader.conf file: (for a zraid pool) zfs_load=YES vfs.root.mountfrom=zfs:zpool (for a linear type) zfs_load=YES vfs.root.mountfrom=zfs:zpool/root If I try any other method, zboot explodes in a myriad of different ways. I hope this helps Peg On Wednesday 17 February 2010 02:49:56 Chris wrote: Scot, I did, as part of step 7 in section 1: 7. Create ZFS Pool zroot Fixit# mkdir /boot/zfs Fixit# zpool create zroot /dev/gpt/disk0 Fixit# zpool set bootfs=zroot zroot ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
Chris, One other thing I just thought of... On all my machines, I have never used the /dev/gpt/ device.. I have always used the absolute name /dev/ada0p3, etc.. Peg On Wednesday 17 February 2010 18:45:47 Chris wrote: Pegasus, Thanks for the tip. I'll give it a shot. If it is the case, then the RootOnZFS wiki guides need to be updated to account for that. They all currently say to use vfs.root.mountfrom=zfs:zroot in loader.conf Thanks, Chris On Wed, Feb 17, 2010 at 1:40 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Chris, Scott Current I use gptzfsboot on my AMD64 (current) machine all the time and also on my laptop. I am not sure if this will cause the problem you are seeing but I know I ran into a lot of trouble depending on what type of pool I was creating. I believe this is correct, and if I am not than I apologise in advance, but If you are trying to boot off a linear type pool (A single disk or a mirror) your bootable filing system has to be a zfs filing system beneath the root pool (IE: zroot/boot). If you are trying to boot off a zraid pool, your bootable filing system must be the root filing system of the pool (IE: zroot) You must also include the appropriate declaration in the /boot/loader.conf file: (for a zraid pool) zfs_load=YES vfs.root.mountfrom=zfs:zpool (for a linear type) zfs_load=YES vfs.root.mountfrom=zfs:zpool/root If I try any other method, zboot explodes in a myriad of different ways. I hope this helps Peg On Wednesday 17 February 2010 02:49:56 Chris wrote: Scot, I did, as part of step 7 in section 1: 7. Create ZFS Pool zroot Fixit# mkdir /boot/zfs Fixit# zpool create zroot /dev/gpt/disk0 Fixit# zpool set bootfs=zroot zroot ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
Pegasus, Thanks for the tip. I'll give it a shot. If it is the case, then the RootOnZFS wiki guides need to be updated to account for that. They all currently say to use vfs.root.mountfrom=zfs:zroot in loader.conf Thanks, Chris On Wed, Feb 17, 2010 at 1:40 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Chris, Scott Current I use gptzfsboot on my AMD64 (current) machine all the time and also on my laptop. I am not sure if this will cause the problem you are seeing but I know I ran into a lot of trouble depending on what type of pool I was creating. I believe this is correct, and if I am not than I apologise in advance, but If you are trying to boot off a linear type pool (A single disk or a mirror) your bootable filing system has to be a zfs filing system beneath the root pool (IE: zroot/boot). If you are trying to boot off a zraid pool, your bootable filing system must be the root filing system of the pool (IE: zroot) You must also include the appropriate declaration in the /boot/loader.conf file: (for a zraid pool) zfs_load=YES vfs.root.mountfrom=zfs:zpool (for a linear type) zfs_load=YES vfs.root.mountfrom=zfs:zpool/root If I try any other method, zboot explodes in a myriad of different ways. I hope this helps Peg On Wednesday 17 February 2010 02:49:56 Chris wrote: Scot, I did, as part of step 7 in section 1: 7. Create ZFS Pool zroot Fixit# mkdir /boot/zfs Fixit# zpool create zroot /dev/gpt/disk0 Fixit# zpool set bootfs=zroot zroot ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
On Wed, February 17, 2010 09:46, Chris wrote: Ok, went back to my 8.0-RELEASE memstick image and after playing with the GPT settings a little and dd'ing all zeros to the disk first, I get a little farther this time. I'm seeing the following: - BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS 631kB/1832448kB available memory FreeBSD/i386 bootstrap loader, Revision 1.0 (root@, Wed Feb 17 10:27:40 UTC 2010) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x8924d8 - And that's as far as it gets. Per the handbook, that appears to be stuck somewhere between boot2 and /boot/loader. To me, it looks like it's having a problem loading the kernel. As far as my suspicion of the BIOS not correctly reporting the drives, it looks to me like the bootloader is seeing them so maybe that can be ruled out. I'm glad to see it get farther this time but this is still weird. Any ideas on this one? Again, another curiousity from my experiences, try booting in verbose mode (#5 in boot screen). If you can't get there, try booting with your installation media, mount the pool and put -v in pool/boot.config. It's kind of a long shot... -- Regards, Doug ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
On Wed, Feb 17, 2010 at 12:40 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Chris, Scott Current I use gptzfsboot on my AMD64 (current) machine all the time and also on my laptop. I am not sure if this will cause the problem you are seeing but I know I ran into a lot of trouble depending on what type of pool I was creating. I believe this is correct, and if I am not than I apologise in advance, but If you are trying to boot off a linear type pool (A single disk or a mirror) your bootable filing system has to be a zfs filing system beneath the root pool (IE: zroot/boot). If you are trying to boot off a zraid pool, your bootable filing system must be the root filing system of the pool (IE: zroot) You must also include the appropriate declaration in the /boot/loader.conf file: (for a zraid pool) zfs_load=YES vfs.root.mountfrom=zfs:zpool (for a linear type) zfs_load=YES vfs.root.mountfrom=zfs:zpool/root If I try any other method, zboot explodes in a myriad of different ways. Not sure why your zboot explodes, but I use a single disk and only use the following in /boot/loader.conf: zfs_load=YES vfs.root.mountfrom=zfs:zpool it should work with either zfs:zpool or zfs:zpool/root. Scot ___ 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: time doesn't work?
Hi, On Sun, Feb 14, 2010 at 10:20 AM, Gavin Atkinson gavinfreebsd@ury.york.ac.uk wrote: /mnt: write failed, filesystem is full gzip: write: No space left on device gzip: output file: randomfile.gz wrong size (1673592832 != -1), deleting gzip: leaving original randomfile 0.000u 85.063s 1:25.10 99.9% 0+0k 12440+12839io 7pf+0w Does reverting r202387, 202441 and 202534 make any difference? Yes, reverting these revisions makes everything back to normal (including top -P). Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ 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: time doesn't work?
On Wed, Feb 17, 2010 at 01:12:53PM -0800, Xin LI wrote: Hi, On Sun, Feb 14, 2010 at 10:20 AM, Gavin Atkinson gavinfreebsd@ury.york.ac.uk wrote: /mnt: write failed, filesystem is full gzip: write: No space left on device gzip: output file: randomfile.gz wrong size (1673592832 != -1), deleting gzip: leaving original randomfile 0.000u 85.063s 1:25.10 99.9% ??0+0k 12440+12839io 7pf+0w Does reverting r202387, 202441 and 202534 make any difference? Yes, reverting these revisions makes everything back to normal (including top -P). I'm not sure this is also related with breakage of systat -vmstat 1 on amd64 CURRENT. systat(1) shows The alternate system clock has died! Reverting to ``pigs'' display. message and does not work as expected. When I run systat(1) on sparc64 CURRENT it worked as expected so I vaguely guess it's related with attilio's change.(CCed) ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
How's this for bizarre? If I hit F12 to bring up the boot menu and select my hard drive, it boots just fine! If I don't do that, with 8.0-STABLE installed, I get the same lba error 1 some number errors as well as the ZFS: i/o error - all block copies unavailable error. Time to call in an exorcist... On Wed, Feb 17, 2010 at 4:03 PM, Scot Hetzel swhet...@gmail.com wrote: On Wed, Feb 17, 2010 at 12:40 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Chris, Scott Current I use gptzfsboot on my AMD64 (current) machine all the time and also on my laptop. I am not sure if this will cause the problem you are seeing but I know I ran into a lot of trouble depending on what type of pool I was creating. I believe this is correct, and if I am not than I apologise in advance, but If you are trying to boot off a linear type pool (A single disk or a mirror) your bootable filing system has to be a zfs filing system beneath the root pool (IE: zroot/boot). If you are trying to boot off a zraid pool, your bootable filing system must be the root filing system of the pool (IE: zroot) You must also include the appropriate declaration in the /boot/loader.conf file: (for a zraid pool) zfs_load=YES vfs.root.mountfrom=zfs:zpool (for a linear type) zfs_load=YES vfs.root.mountfrom=zfs:zpool/root If I try any other method, zboot explodes in a myriad of different ways. Not sure why your zboot explodes, but I use a single disk and only use the following in /boot/loader.conf: zfs_load=YES vfs.root.mountfrom=zfs:zpool it should work with either zfs:zpool or zfs:zpool/root. Scot ___ 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] Fix LOR #185
On Monday 15 February 2010 2:49:32 pm Matthew Fleming wrote: We've seen LOR #185 on http://sources.zabbadoz.net/freebsd/lor.html locally on and off since October 2007. This patch has been compiled but I don't have a reliable way to repro the LOR so it's not been properly tested. If someone who has seen this LOR can confirm the patch fixes it, and could commit, that would be nice. The patch looks right to me. I will commit it. -- John Baldwin ___ 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 DEADLKRES
My r203753 amd64 laptop falls into the deadlock situation every night while running periodic daily script. I am pretty certain this is related to ZFS. I have enabled DEADLKRES in the kernel. I even have a separate dump partition (not used for swap). Indeed, the kernel deadlock detector gets triggered during the periodic run, but I get I/O error when calling doadump() from DDB. Dumping works properly when DDB is invoked with keyboard escape. What's the best way to troubleshoot this deadlock? Should I try to transcribe alltrace output? -- Marcin Cieslak // sa...@saper.info ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
As a follow-up to this, I rebuilt world and kernel and updated my system to the latest 8.0-STABLE. I'm still seeing the problem and I can still get around it by choosing my hard drive from the F12 boot menu. I did notice that the bootloader now says it's ZFS enabled whereas it didn't while on 8.0-RELEASE. I also updated the bootcode with: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 adX after installing world. No help there. It seems to me that there's a difference in the way the ZFS-enabled bootloader sees the drives that the BIOS reports as opposed to the non-ZFS-enabled bootloader. Anyone have any ideas on that? I checked for any BIOS updates but it looks like I'm current. It sure would be nice to not have to select my hard drive each time. Thanks, Chris On Wed, Feb 17, 2010 at 5:16 PM, Chris behrnetwo...@gmail.com wrote: How's this for bizarre? If I hit F12 to bring up the boot menu and select my hard drive, it boots just fine! If I don't do that, with 8.0-STABLE installed, I get the same lba error 1 some number errors as well as the ZFS: i/o error - all block copies unavailable error. Time to call in an exorcist... On Wed, Feb 17, 2010 at 4:03 PM, Scot Hetzel swhet...@gmail.com wrote: On Wed, Feb 17, 2010 at 12:40 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Chris, Scott Current I use gptzfsboot on my AMD64 (current) machine all the time and also on my laptop. I am not sure if this will cause the problem you are seeing but I know I ran into a lot of trouble depending on what type of pool I was creating. I believe this is correct, and if I am not than I apologise in advance, but If you are trying to boot off a linear type pool (A single disk or a mirror) your bootable filing system has to be a zfs filing system beneath the root pool (IE: zroot/boot). If you are trying to boot off a zraid pool, your bootable filing system must be the root filing system of the pool (IE: zroot) You must also include the appropriate declaration in the /boot/loader.conf file: (for a zraid pool) zfs_load=YES vfs.root.mountfrom=zfs:zpool (for a linear type) zfs_load=YES vfs.root.mountfrom=zfs:zpool/root If I try any other method, zboot explodes in a myriad of different ways. Not sure why your zboot explodes, but I use a single disk and only use the following in /boot/loader.conf: zfs_load=YES vfs.root.mountfrom=zfs:zpool it should work with either zfs:zpool or zfs:zpool/root. Scot ___ 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: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
On Wed, Feb 17, 2010 at 7:49 PM, Chris behrnetwo...@gmail.com wrote: As a follow-up to this, I rebuilt world and kernel and updated my system to the latest 8.0-STABLE. I'm still seeing the problem and I can still get around it by choosing my hard drive from the F12 boot menu. I did notice that the bootloader now says it's ZFS enabled whereas it didn't while on 8.0-RELEASE. I also updated the bootcode with: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 adX after installing world. No help there. It seems to me that there's a difference in the way the ZFS-enabled bootloader sees the drives that the BIOS reports as opposed to the non-ZFS-enabled bootloader. Anyone have any ideas on that? I checked for any BIOS updates but it looks like I'm current. It sure would be nice to not have to select my hard drive each time. Can you paste the exact error? Are you getting something like: error 1: lba 32 error 1: lba 1 When I've seen the above sequence, it was due to a stack overflow (IIRC), with the result that the loader would start a second time and barf out these errors. The large number in the error might give us a clue as to what's going on. If the number is really large, it might be an indication that your BIOS doesn't reliably read past a certain threshold. ZFS writes a sort of label at the beginning and end of its drives; perhaps the loader is trying to read the label at the end of the disk and is failing (I don't recall whether it tries to read both labels). Matt ___ 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
