From owner-freebsd-fs@FreeBSD.ORG Mon Nov 16 11:06:52 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F00C106568F for ; Mon, 16 Nov 2009 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 296408FC1C for ; Mon, 16 Nov 2009 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAGB6qc4011150 for ; Mon, 16 Nov 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAGB6pMW011148 for freebsd-fs@FreeBSD.org; Mon, 16 Nov 2009 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Nov 2009 11:06:51 GMT Message-Id: <200911161106.nAGB6pMW011148@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 11:06:52 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/140433 fs [zfs] [panic] panic while replaying ZIL after crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138367 fs [tmpfs] [panic] 'panic: Assertion pages > 0 failed' wh o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/138109 fs [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2f f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 135 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 16 13:35:37 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D23F106568F for ; Mon, 16 Nov 2009 13:35:37 +0000 (UTC) (envelope-from aaron@goflexitllc.com) Received: from mail.goflexitllc.com (mail.goflexitllc.com [70.38.81.12]) by mx1.freebsd.org (Postfix) with ESMTP id AB9318FC0A for ; Mon, 16 Nov 2009 13:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=goflexitllc.com; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=zeta; bh=y/mqTuBiO8eqtrd6zUlI2TkWtk M=; b=Ru+YOWQBF1Jh5T2xXh4vnT49waAkgTsqSFWETDpXu20B4rqiB6IAot5/T9 JlD0GfQqCAi6zmIagxCiRzz8uqB/kMTovevPvVG5Ey1s5RCv4SAh74aW7c4beYd4 ORqMBE DomainKey-Signature: a=rsa-sha1; c=nofws; d=goflexitllc.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=zeta; b=PquLaIWI3gjeIj7g7Ik0 brPun/8PzVKIFTOVVgco+Kj2dWjU47wR+OtuOE2Hf+cuY9+vna3Fpb3eQN8s4xl0 K8IyvZ53vEZ8emaFGzSrfRACExdu9UsQ2RE56T4djJ9G Received: (qmail 96496 invoked by uid 89); 16 Nov 2009 13:35:33 -0000 Received: (simscan 1.4.1 ppid 96487 pid 96493 t 0.1964s) (scanners: regex: 1.4.1 attach: 1.4.1 clamav: 0.95.2/m:51/d:10027); 16 Nov 0109 13:35:33 -0000 Received: from temp4.wavelinx.net (HELO ?172.16.1.128?) (aaron@goflexitllc.com@69.27.151.4) by mail.goflexitllc.com with ESMTPA; 16 Nov 2009 13:35:33 -0000 Message-ID: <4B015520.7080109@goflexitllc.com> Date: Mon, 16 Nov 2009 07:35:28 -0600 From: Aaron Hurt User-Agent: Thunderbird 2.0.0.23 (X11/20091001) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <1A8F306A-8749-471B-94EA-FC8435A30C34@yellowspace.net> <4AFF15AE.4070902@quip.cz> In-Reply-To: <4AFF15AE.4070902@quip.cz> Content-Type: multipart/mixed; boundary="------------010909020406010003050503" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: gmirroring slices X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:35:37 -0000 This is a multi-part message in MIME format. --------------010909020406010003050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Miroslav Lachman wrote: > Lorenzo Perone wrote: >> >> Hello, >> >> I was wondering if anyone could give me an advice on how viable and >> reliable it is, to use gmirror on a slice of an MBR-style partitioned >> disk, and use the second slice(s) within a zpool. >> >> I remember a discussion here on where metadata is kept (always at the >> end of the disk as opposed to the end of the given consumer?), so I >> wasn't sure about how much of a good idea this might be. > > I think metadata is stored at the end of the provider (slice in this > case), but I am not a GEOM expert. > >> The reason I'd >> like to have it like this is, that I had mixed bad experiences in the >> effort of using ZFS as a boot and root volume, so I'd rather keep a >> traditional slice for booting/rooting, and a zpool for the production >> jails on that machine. >> >> The example would be >> >> provider: mirror/gm0 >> consumers: ad6s1 and ad8s1 >> >> zpool mirror made out of >> ad6s2 and ad8s2 > > I am running following setup for year without any configuration problems > > # gmirror status > Name Status Components > mirror/gms1 COMPLETE ad4s1 > ad6s1 > > # zpool status > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror ONLINE 0 0 0 > ad4s2 ONLINE 0 0 0 > ad6s2 ONLINE 0 0 0 > > The first slice is 20GB partitioned as usual: > # mount -t ufs > /dev/mirror/gms1a on / (ufs, local) > /dev/mirror/gms1e on /usr (ufs, local, soft-updates) > /dev/mirror/gms1d on /var (ufs, local, nosuid, soft-updates) > /dev/mirror/gms1f on /tmp (ufs, local, noexec, nosuid, soft-updates) > > The rest (450GB) is used in ZFS mirrored zpool for jails (each jail > has its own filesystem) > >> while experimenting, I got into the problem that gmirror label -v -b >> round-robin gm0 ad6s1 got a permission denied (even with sysctl >> kern.geom.debugflags=16/17). Any hints on what can cause this (I might >> have screwed up something with fdisk/bsdlabel, but after doublechecking >> I wonder what it could be..) > > I did it in non-standard way - converting already installed system on > one disk to mirrored. So when I was in system running off ad6 I > created two slices on ad4, setup gmirror gms1 from first slice of ad4, > create partitions, newfs, mount it and transfer files from running > system by dump & restore, edit fstab. Then I rebooted system from > gms1, destroy content of ad6, create slices on ad6 and insert first > slice in to gms1. > After this I had ad4s2 and ad6s2 ready for zpool. > All was done remotely through ssh. > > Miroslav Lachman > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > !DSPAM:2,4aff15c1775218542073880! > An example with gpart ... this is how I know have all of my production dedicated servers setup and running 8.0-RCx ... net1# gpart show => 34 312581741 ad6 GPT (149G) 34 128 1 freebsd-boot (64K) 162 8388608 2 freebsd-swap (4.0G) 8388770 10485760 3 freebsd-ufs (5.0G) 18874530 293707245 4 freebsd-zfs (140G) => 34 312581741 ad16 GPT (149G) 34 128 1 freebsd-boot (64K) 162 8388608 2 freebsd-swap (4.0G) 8388770 10485760 3 freebsd-ufs (5.0G) 18874530 293707245 4 freebsd-zfs (140G) net1# gmirror status Name Status Components mirror/boot COMPLETE ad6p1 ad16p1 mirror/swap COMPLETE ad6p2 ad16p2 mirror/root COMPLETE ad6p3 ad16p3 net1# zpool status pool: pool0 state: ONLINE scrub: scrub completed after 0h5m with 0 errors on Wed Oct 14 12:45:40 2009 config: NAME STATE READ WRITE CKSUM pool0 ONLINE 0 0 0 mirror ONLINE 0 0 0 ad6p4 ONLINE 0 0 0 ad16p4 ONLINE 0 0 0 errors: No known data errors net1# mount -t ufs /dev/mirror/root on / (ufs, local, soft-updates) net1# mount -t zfs pool0 on /pool0 (zfs, local) pool0/tmp on /tmp (zfs, local, nosuid) pool0/usr on /usr (zfs, local) pool0/usr/home on /usr/home (zfs, local) pool0/usr/hosting on /usr/hosting (zfs, local, noexec, nosuid) pool0/usr/ports on /usr/ports (zfs, local, nosuid) pool0/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noexec, nosuid) pool0/usr/ports/packages on /usr/ports/packages (zfs, local, noexec, nosuid) pool0/usr/src on /usr/src (zfs, local, noexec, nosuid) pool0/var on /var (zfs, local) pool0/var/crash on /var/crash (zfs, local, noexec, nosuid) pool0/var/db on /var/db (zfs, local, noexec, nosuid) pool0/var/db/pkg on /var/db/pkg (zfs, local, nosuid) pool0/var/empty on /var/empty (zfs, local, noexec, nosuid, read-only) pool0/var/log on /var/log (zfs, local, noexec, nosuid) pool0/var/mail on /var/mail (zfs, local, noexec, nosuid) pool0/var/qmail on /var/qmail (zfs, local) pool0/var/run on /var/run (zfs, local, noexec, nosuid) pool0/var/tmp on /var/tmp (zfs, local, nosuid) It runs great and I haven't experienced any issues related to sharing disks between ufs and zfs using gpt partitioning. -- Aaron Hurt Managing Partner Flex I.T., LLC 611 Commerce Street Suite 3117 Nashville, TN 37203 Phone: 615.438.7101 E-mail: aaron@goflexitllc.com --------------010909020406010003050503-- From owner-freebsd-fs@FreeBSD.ORG Mon Nov 16 16:43:59 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420521065672; Mon, 16 Nov 2009 16:43:59 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 97B028FC0A; Mon, 16 Nov 2009 16:43:58 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id D7D7E28; Mon, 16 Nov 2009 17:30:21 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Mon, 16 Nov 2009 17:26:10 +0100 To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:43:59 -0000 After installkernel/installworld my machine stops booting with the following error message: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type lld FreeBSD/i386 boot Default: pgpool:/boot/kernel/kernel boot: ZFS: unexpected object set type lld This is 7.2-STABLE, amd64, zpool on single logical device (ciss(4), hardware RAID5), root on ZFS (using zfsboot). After the failure I booted the server from an external device with UFS and then I did rollback of /usr and / datasets. The machine was still not bootable. Scrub went without errors. Then I read this thread and applied Robert Noland's and Matt Reimer's patches -- and they didn't help. Then I grabbed following files from -CURRENT (svn rev. 198420): /sys/boot/i386/zfsboot/zfsboot.c /sys/boot/zfs/zfs.c /sys/boot/zfs/zfsimpl.c /sys/cddl/boot/zfs/zfsimpl.h and I did: # cd /usr/src/sys/boot/ # make obj ; make depend ; make # cd i386/loader # make install # cd /usr/src/sys/boot/i386/zfsboot # make install # sysctl kern.geom.debugflags=16 # dd if=/boot/zfsboot of=/dev/da0 count=1 # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 # reboot (is this procedure of updating zfsboot correct?) After that, an error was slightly different (printf was fixed): ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type 0 FreeBSD/i386 boot Default: pgpool:/boot/kernel/kernel boot: ZFS: unexpected object set type 0 Additional information: # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT pgpool 4.06T 2.17T 1.89T 53% ONLINE - # zpool status pool: pgpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM pgpool ONLINE 0 0 0 da0 ONLINE 0 0 0 errors: No known data errors # zfs list pgpool/ROOTFS NAME USED AVAIL REFER MOUNTPOINT pgpool/ROOTFS 568M 1.80T 55.3M legacy # zpool get all pgpool NAME PROPERTY VALUE SOURCE pgpool size 4.06T - pgpool used 2.17T - pgpool available 1.89T - pgpool capacity 53% - pgpool altroot - default pgpool health ONLINE - pgpool guid 3920915583055727184 - pgpool version 13 default pgpool bootfs pgpool/ROOTFS local pgpool delegation on default pgpool autoreplace off default pgpool cachefile - default pgpool failmode wait default pgpool listsnapshots off default loader.conf: usb_load="YES" uplcom_load="YES" umass_load="YES" ugen_load="YES" ukbd_load="YES" random_load="YES" loader_color="YES" vfs.root.mountfrom="zfs:pgpool/ROOTFS" zfs_load="YES" autoboot_delay="2" FreeBSD 7.2-STABLE #0: Fri Jun 19 13:27:29 CEST 2009 (as I mentioned above, there was the rollback) ciss0: port 0xe800-0xe8ff mem 0xdef00000-0xdeffffff,0xdeeff000-0xdeefffff irq 35 at device 0.0 on pci4 ciss0: [ITHREAD] da0 at ciss0 bus 0 target 0 lun 0 I would rather not to upgrade the whole system to -CURRENT. What should I do in this situation? Is there any other patch that I could apply or any workaround for this issue? Is there possibility to switch from zfsboot to gptzfsboot without loosing data? Or maybe I did something wrong? -- am From owner-freebsd-fs@FreeBSD.ORG Mon Nov 16 16:59:54 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6A2106566B; Mon, 16 Nov 2009 16:59:54 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D748D8FC1E; Mon, 16 Nov 2009 16:59:53 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAGGxnp1081455 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 11:59:50 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Mon, 16 Nov 2009 10:59:44 -0600 Message-Id: <1258390784.2303.42.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:59:54 -0000 On Mon, 2009-11-16 at 17:26 +0100, Emil Smolenski wrote: > After installkernel/installworld my machine stops booting with the > following error message: > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type lld > > FreeBSD/i386 boot > Default: pgpool:/boot/kernel/kernel > boot: > ZFS: unexpected object set type lld > > This is 7.2-STABLE, amd64, zpool on single logical device (ciss(4), > hardware RAID5), root on ZFS (using zfsboot). After the failure I booted > the server from an external device with UFS and then I did rollback of > /usr and / datasets. The machine was still not bootable. Scrub went > without errors. > Then I read this thread and applied Robert Noland's and Matt Reimer's > patches -- and they didn't help. Then I grabbed following files from > -CURRENT (svn rev. 198420): Matt's patch only effects raidz volumes. > /sys/boot/i386/zfsboot/zfsboot.c > /sys/boot/zfs/zfs.c > /sys/boot/zfs/zfsimpl.c > /sys/cddl/boot/zfs/zfsimpl.h > > and I did: > > # cd /usr/src/sys/boot/ > # make obj ; make depend ; make > # cd i386/loader > # make install > # cd /usr/src/sys/boot/i386/zfsboot > # make install > # sysctl kern.geom.debugflags=16 > # dd if=/boot/zfsboot of=/dev/da0 count=1 > # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > # reboot > > (is this procedure of updating zfsboot correct?) This should be correct for updating the first stage bootstrap code. The loader (boot/loader) is actually updated during installworld. > After that, an error was slightly different (printf was fixed): > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type 0 This has my patch applied, which fixes the printf's so that they work correctly among other things. > FreeBSD/i386 boot > Default: pgpool:/boot/kernel/kernel > boot: > ZFS: unexpected object set type 0 > > Additional information: > > # zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > pgpool 4.06T 2.17T 1.89T 53% ONLINE - > > # zpool status > pool: pgpool > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > pgpool ONLINE 0 0 0 > da0 ONLINE 0 0 0 > > errors: No known data errors > > # zfs list pgpool/ROOTFS > NAME USED AVAIL REFER MOUNTPOINT > pgpool/ROOTFS 568M 1.80T 55.3M legacy > > # zpool get all pgpool > NAME PROPERTY VALUE SOURCE > pgpool size 4.06T - > pgpool used 2.17T - > pgpool available 1.89T - > pgpool capacity 53% - > pgpool altroot - default > pgpool health ONLINE - > pgpool guid 3920915583055727184 - > pgpool version 13 default > pgpool bootfs pgpool/ROOTFS local > pgpool delegation on default > pgpool autoreplace off default > pgpool cachefile - default > pgpool failmode wait default > pgpool listsnapshots off default > > loader.conf: > usb_load="YES" > uplcom_load="YES" > umass_load="YES" > ugen_load="YES" > ukbd_load="YES" > random_load="YES" > loader_color="YES" > vfs.root.mountfrom="zfs:pgpool/ROOTFS" > zfs_load="YES" > autoboot_delay="2" > > FreeBSD 7.2-STABLE #0: Fri Jun 19 13:27:29 CEST 2009 > (as I mentioned above, there was the rollback) > > ciss0: port 0xe800-0xe8ff mem > 0xdef00000-0xdeffffff,0xdeeff000-0xdeefffff irq 35 at device 0.0 on pci4 > ciss0: [ITHREAD] > da0 at ciss0 bus 0 target 0 lun 0 > > I would rather not to upgrade the whole system to -CURRENT. What should I > do in this situation? Is there any other patch that I could apply or any > workaround for this issue? Is there possibility to switch from zfsboot to > gptzfsboot without loosing data? Or maybe I did something wrong? I don't think that you can switch to gptzfsboot as that would require repartitioning the device. A little more context though, was this working before? Or is this a new install? robert. -- Robert Noland FreeBSD From owner-freebsd-fs@FreeBSD.ORG Mon Nov 16 18:33:33 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B69AA106568D; Mon, 16 Nov 2009 18:33:33 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 525D48FC15; Mon, 16 Nov 2009 18:33:33 +0000 (UTC) Received: from bolt.zol (unknown [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 1E37728; Mon, 16 Nov 2009 19:37:40 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> Date: Mon, 16 Nov 2009 19:33:34 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: <1258390784.2303.42.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:33:33 -0000 On Mon, 16 Nov 2009 17:59:44 +0100, Robert Noland wrote: >> [...] >> Then I read this thread and applied Robert Noland's and Matt Reimer's >> patches -- and they didn't help. Then I grabbed following files from >> -CURRENT (svn rev. 198420): > Matt's patch only effects raidz volumes. Oh, I see. Maybe there is similar bug in ZFS on single disk volumes also? >> [cut: update procedure] >> (is this procedure of updating zfsboot correct?) > This should be correct for updating the first stage bootstrap code. The > loader (boot/loader) is actually updated during installworld. I'll try full build/installworld tomorrow. >> [...] >> I would rather not to upgrade the whole system to -CURRENT. What >> should I >> do in this situation? Is there any other patch that I could apply or any >> workaround for this issue? Is there possibility to switch from zfsboot >> to >> gptzfsboot without loosing data? Or maybe I did something wrong? > I don't think that you can switch to gptzfsboot as that would require > repartitioning the device. I thought so. > A little more context though, was this working before? Or is this a new > install? This system has worked stable since Jun, but I've never done full installworld after the initial installation. Now, after the installworld, machine no longer boots. (Rollback did not help). -- am From owner-freebsd-fs@FreeBSD.ORG Tue Nov 17 04:10:54 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A74C1106566B for ; Tue, 17 Nov 2009 04:10:52 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 395358FC0A for ; Tue, 17 Nov 2009 04:10:51 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so1339420fga.13 for ; Mon, 16 Nov 2009 20:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=eL/UX6rRaRygweUP+MUx+c1qeLUqPuYh1pF5OdVb5yE=; b=OM4bmU8JWxsnv6RwGtxHiHAXQ+H0M42TuYrfj2eUZWHsfX0Wbv+ZTK46aufyZDNO6n BH/EZQPJkRt3a8T9OpUNB3UbQ4+7sKzjik76NMX8iXwt9MR35ZYVPl73oIwT6g2h7dod 33N8paXg2wZrcoDO41V2kaST3tyqx3RbWKEUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=ilupfoxHqFD2KlO5LreC+PFKFE1IKbEqQtjJK4eeWwDf9+XKeuKFvRpUDoDwthvy9o SY1z13A7QhSCho/tChDplv8uBLKnjfB7Eg51CWaDIW55uS3CzWaX0W04hLe3O5HLH3CR HycGk9wRmDGN3OcJ9t0G7gF0cy7wjtv+iJrRI= Received: by 10.103.85.28 with SMTP id n28mr4077533mul.66.1258431051068; Mon, 16 Nov 2009 20:10:51 -0800 (PST) Received: from ?10.0.0.10? (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id 12sm15844901muq.18.2009.11.16.20.10.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 20:10:50 -0800 (PST) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Nov 2009 06:10:46 +0200 Message-Id: <982FC0F3-0071-41E7-94A5-A49720B1771B@gmail.com> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: ZFS resilver/replace changed vdev names from da(4) to gptid X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 04:10:54 -0000 Hello, Something strange happened while resilvering a 6 disk raidz1 array with = one failed drive. I've initially put the new disk and issued : zfs replace tank da1p2 But the resilver process found unrecoverable errors in one snapshot and = after resilvering for 7 hours it still showed da1p2/old and the new da1p2 and shortly after this after = issuing another zfs scrub command the machine livelocked. The strange thing happened after I rebooted the machine and restarted = the zfs scrub. This time ZFS picked up the new device not by da(4) name, but by gptid, = this pass also failed and I was forced to destroy a snapshot containing the unrecoverable errors and restart the = scrub again. This time it completed normally and the pool is now ONLINE but even more = strangely this time it replaced another vdev with it's gptid, and this is not the vdev that was being resilvered... = and now the pool looks like this : pool: tank state: ONLINE scrub: resilver completed after 7h18m with 0 errors on Tue Nov 17 = 00:16:20 2009 config: NAME STATE READ = WRITE CKSUM tank ONLINE 0 = 0 0 raidz1 ONLINE 0 = 0 0 da0p2 ONLINE 0 = 0 0 4.55G resilvered gptid/b8baba94-d068-11de-a6d5-003048c1b5fa ONLINE 0 = 0 0 63.2G resilvered gptid/c00174b1-d068-11de-a6d5-003048c1b5fa ONLINE 0 = 0 0 4.55G resilvered da3p2 ONLINE 0 = 0 0 4.21G resilvered da4p2 ONLINE 0 = 0 0 4.55G resilvered da5p2 ONLINE 0 = 0 0 4.21G resilvered errors: No known data errors P.S.: This also makes me wonder how I can safely make all of the other = vdevs use gptid, as I plan to replace the SATA controller with a new one that probably is going to export the = devices as ad(4) or ada(4). -- Regards, Nikolay Denev From owner-freebsd-fs@FreeBSD.ORG Tue Nov 17 09:00:54 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D96741065672 for ; Tue, 17 Nov 2009 09:00:54 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC438FC18 for ; Tue, 17 Nov 2009 09:00:54 +0000 (UTC) Received: by bwz5 with SMTP id 5so6948055bwz.3 for ; Tue, 17 Nov 2009 01:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qcctAhJSsu6x0FwGW/C7I+s2k283gtpFDzPmmSvNxfk=; b=fUBuA/SdoQ0l+4LKZtvbvAmNyPXRlq5TSb9o+5ZprbeHs/GtlrzIkcR7Xd4IVd9PZ3 htg/ihAMudsEmEYmsiJO1jDrjj6TAf/B8bOD99l0L20AEYng+v7ePQrBz2qVLB33eNJI i6unlXn7YS0EmAXywfCk1tFma67JDLs9buU8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OqHDXSrUCdBlkz+1N+D0i2D7V0S6m6aqTjvHqpPbXz2BXiHrH+SyTPdYjpTewetEGA 9KWsV7W3dj/qJ6czJxUokbuqFPNmtf8IaIVqFgzV4T9lqqfh2Sg1lbND9496SkFvmUVB 2pq+x3Fdlzux8SqM4sKsQxScSlpYNb5cC66wU= MIME-Version: 1.0 Received: by 10.204.8.138 with SMTP id h10mr5708405bkh.187.1258448453389; Tue, 17 Nov 2009 01:00:53 -0800 (PST) In-Reply-To: <982FC0F3-0071-41E7-94A5-A49720B1771B@gmail.com> References: <982FC0F3-0071-41E7-94A5-A49720B1771B@gmail.com> Date: Tue, 17 Nov 2009 11:00:53 +0200 Message-ID: <2e77fc10911170100i7a867706mf6887759a963b248@mail.gmail.com> From: Niki Denev To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: ZFS resilver/replace changed vdev names from da(4) to gptid X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:00:54 -0000 On Tue, Nov 17, 2009 at 6:10 AM, Nikolay Denev wrote: [snip] > P.S.: This also makes me wonder how I can safely make all of the other vdevs use gptid, as I plan to replace > the SATA controller with a new one that probably is going to export the devices as ad(4) or ada(4). Reading the manual always helps :) In this case a "zpool export" and then "zpool import -d /dev/gptid" should do the trick. > -- > Regards, > Nikolay Denev From owner-freebsd-fs@FreeBSD.ORG Tue Nov 17 15:38:09 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCD2D1065695 for ; Tue, 17 Nov 2009 15:38:09 +0000 (UTC) (envelope-from josh@multipart-mixed.com) Received: from joshcarter.com (67-207-137-80.slicehost.net [67.207.137.80]) by mx1.freebsd.org (Postfix) with ESMTP id BD7948FC14 for ; Tue, 17 Nov 2009 15:38:09 +0000 (UTC) Received: from [192.168.1.101] (unknown [74.7.182.1]) by joshcarter.com (Postfix) with ESMTPSA id C5287C83D8; Tue, 17 Nov 2009 15:38:08 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Josh Carter In-Reply-To: <982FC0F3-0071-41E7-94A5-A49720B1771B@gmail.com> Date: Tue, 17 Nov 2009 08:38:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <982FC0F3-0071-41E7-94A5-A49720B1771B@gmail.com> To: Nikolay Denev X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS resilver/replace changed vdev names from da(4) to gptid X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:38:09 -0000 Nikolay, > P.S.: This also makes me wonder how I can safely make all of the other = vdevs use gptid, as I plan to replace > the SATA controller with a new one that probably is going to export = the devices as ad(4) or ada(4). As you mentioned in your follow-up email, I've always found a "zpool = export" and "zpool import" to cure all ills when drive logical = assignments change. It forces ZFS to forget everything it thinks it = knows about the pool and re-create that knowledge from what's on the = disk(s). I've had to do this after reconfiguring systems both on = OpenSolaris and FreeBSD. Best regards, Josh From owner-freebsd-fs@FreeBSD.ORG Tue Nov 17 15:47:56 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B110A1065696; Tue, 17 Nov 2009 15:47:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 891E88FC1F; Tue, 17 Nov 2009 15:47:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAHFluFh038378; Tue, 17 Nov 2009 15:47:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAHFluiY038374; Tue, 17 Nov 2009 15:47:56 GMT (envelope-from linimon) Date: Tue, 17 Nov 2009 15:47:56 GMT Message-Id: <200911171547.nAHFluiY038374@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140640: [zfs] snapshot crash X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:47:56 -0000 Old Synopsis: ZFS - Snapshot Crash New Synopsis: [zfs] snapshot crash Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 17 15:47:29 UTC 2009 Responsible-Changed-Why: make this a 'kern' PR and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=140640 From owner-freebsd-fs@FreeBSD.ORG Tue Nov 17 21:43:51 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FD051065767; Tue, 17 Nov 2009 21:43:51 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7945A8FC1A; Tue, 17 Nov 2009 21:43:50 +0000 (UTC) Received: from bolt.zol (62-121-98-25.home.aster.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 1885250; Tue, 17 Nov 2009 22:47:56 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> Date: Tue, 17 Nov 2009 22:43:46 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:43:51 -0000 On Mon, 16 Nov 2009 19:33:34 +0100, Emil Smolenski wrote: >> Matt's patch only effects raidz volumes. > Oh, I see. Maybe there is similar bug in ZFS on single disk volumes > also? >>> (is this procedure of updating zfsboot correct?) >> This should be correct for updating the first stage bootstrap code. The >> loader (boot/loader) is actually updated during installworld. > > I'll try full build/installworld tomorrow. It, unfortunately, didn't solve this issue. Should I file a PR? I would like to help in debugging it (however my skills in low-level C aren't strong enough to do it on my own). -- am From owner-freebsd-fs@FreeBSD.ORG Tue Nov 17 22:33:51 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049C9106566B; Tue, 17 Nov 2009 22:33:51 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C10568FC0C; Tue, 17 Nov 2009 22:33:50 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAHMXlVa012182 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 17:33:48 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Tue, 17 Nov 2009 16:33:41 -0600 Message-Id: <1258497221.2303.66.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:33:51 -0000 On Tue, 2009-11-17 at 22:43 +0100, Emil Smolenski wrote: > On Mon, 16 Nov 2009 19:33:34 +0100, Emil Smolenski > wrote: > > >> Matt's patch only effects raidz volumes. > > Oh, I see. Maybe there is similar bug in ZFS on single disk volumes > > also? > > >>> (is this procedure of updating zfsboot correct?) > >> This should be correct for updating the first stage bootstrap code. The > >> loader (boot/loader) is actually updated during installworld. > > > > I'll try full build/installworld tomorrow. > > It, unfortunately, didn't solve this issue. Should I file a PR? I would > like to help in debugging it (however my skills in low-level C aren't > strong enough to do it on my own). Ok, the first thing I would like to see is "zdb -uuu". I don't see an obvious issue with single disk reads. My own setup uses 2 x 1TB currently. Failing to read the MOS is basically the first read attempt from the pool, in fact it is the read that attempts to mount the pool. robert. -- Robert Noland FreeBSD From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 00:17:22 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5DCA1065676; Wed, 18 Nov 2009 00:17:22 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0278FC0A; Wed, 18 Nov 2009 00:17:22 +0000 (UTC) Received: from bolt.zol (62-121-98-25.home.aster.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 10BFE66D; Wed, 18 Nov 2009 01:21:28 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 01:17:20 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: <1258497221.2303.66.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:17:22 -0000 On Tue, 17 Nov 2009 23:33:41 +0100, Robert Noland wrote: >> Should I file a PR? I would >> like to help in debugging it (however my skills in low-level C aren't >> strong enough to do it on my own). > Ok, the first thing I would like to see is "zdb -uuu". # zdb -uuu pgpool Segmentation fault: 11 (core dumped) # zdb pgpool version=13 name='pgpool' state=0 txg=439808 pool_guid=3920915583055727184 hostid=1642959122 hostname='unset' vdev_tree type='root' id=0 guid=3920915583055727184 children[0] type='disk' id=0 guid=5859773264564918193 path='/dev/da0' whole_disk=0 metaslab_array=23 metaslab_shift=35 ashift=9 asize=4500799356928 is_log=0 DTL=260 > I don't see an > obvious issue with single disk reads. My own setup uses 2 x 1TB > currently. Failing to read the MOS is basically the first read attempt > from the pool, in fact it is the read that attempts to mount the pool. -- am From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 13:51:00 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA56106566B; Wed, 18 Nov 2009 13:51:00 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id EE1BE8FC1A; Wed, 18 Nov 2009 13:50:59 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAIDorqT016998 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 08:50:54 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Wed, 18 Nov 2009 07:50:47 -0600 Message-Id: <1258552247.2303.75.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 13:51:00 -0000 On Wed, 2009-11-18 at 01:17 +0100, Emil Smolenski wrote: > On Tue, 17 Nov 2009 23:33:41 +0100, Robert Noland > wrote: > > >> Should I file a PR? I would > >> like to help in debugging it (however my skills in low-level C aren't > >> strong enough to do it on my own). > > > Ok, the first thing I would like to see is "zdb -uuu". > > # zdb -uuu pgpool > Segmentation fault: 11 (core dumped) Ok, this is disturbing... It works fine for me on -CURRENT / amd64 and reports the root block pointer, which is what we need to locate the MOS. robert. > # zdb > pgpool > version=13 > name='pgpool' > state=0 > txg=439808 > pool_guid=3920915583055727184 > hostid=1642959122 > hostname='unset' > vdev_tree > type='root' > id=0 > guid=3920915583055727184 > children[0] > type='disk' > id=0 > guid=5859773264564918193 > path='/dev/da0' > whole_disk=0 > metaslab_array=23 > metaslab_shift=35 > ashift=9 > asize=4500799356928 > is_log=0 > DTL=260 > > > I don't see an > > obvious issue with single disk reads. My own setup uses 2 x 1TB > > currently. Failing to read the MOS is basically the first read attempt > > from the pool, in fact it is the read that attempts to mount the pool. > -- Robert Noland FreeBSD From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 16:11:21 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63614106568B; Wed, 18 Nov 2009 16:11:21 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 037388FC12; Wed, 18 Nov 2009 16:11:20 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 1A0EF244; Wed, 18 Nov 2009 17:15:24 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 17:11:14 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: In-Reply-To: <1258552247.2303.75.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:11:21 -0000 On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland wrote: >> >> Should I file a PR? I would >> >> like to help in debugging it (however my skills in low-level C aren't >> >> strong enough to do it on my own). >> > Ok, the first thing I would like to see is "zdb -uuu". >> # zdb -uuu pgpool >> Segmentation fault: 11 (core dumped) > Ok, this is disturbing... It works fine for me on -CURRENT / amd64 and > reports the root block pointer, which is what we need to locate the MOS. Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb -uuu" happy: Fixit# zdb -uuu pgpool Uberblock magic = 0000000000bab10c version = 13 txg = 443448 guid_sum = 9780688847620645377 timestamp = 1258560175 UTC = Wed Nov 18 16:02:55 2009 rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:220000de400:200> DVA[1]=<0:2a80008ee00:200> DVA[2]=<0:330000b9000:200> fletcher4 lzjb LE contiguous birth=443448 fill=298 cksum=8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac -- am From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 16:43:57 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4126106566B; Wed, 18 Nov 2009 16:43:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8912C8FC1B; Wed, 18 Nov 2009 16:43:57 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-215.bna.bellsouth.net [74.241.172.215]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAIGhs30018338 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 11:43:55 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Wed, 18 Nov 2009 10:43:48 -0600 Message-Id: <1258562628.2303.83.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:43:57 -0000 On Wed, 2009-11-18 at 17:11 +0100, Emil Smolenski wrote: > On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland > wrote: > > >> >> Should I file a PR? I would > >> >> like to help in debugging it (however my skills in low-level C aren't > >> >> strong enough to do it on my own). > >> > Ok, the first thing I would like to see is "zdb -uuu". > >> # zdb -uuu pgpool > >> Segmentation fault: 11 (core dumped) > > > Ok, this is disturbing... It works fine for me on -CURRENT / amd64 and > > reports the root block pointer, which is what we need to locate the MOS. > > Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb -uuu" > happy: > > Fixit# zdb -uuu pgpool > Uberblock > > magic = 0000000000bab10c > version = 13 > txg = 443448 > guid_sum = 9780688847620645377 > timestamp = 1258560175 UTC = Wed Nov 18 16:02:55 2009 > rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:220000de400:200> > DVA[1]=<0:2a80008ee00:200> DVA[2]=<0:330000b9000:200> fletcher4 lzjb LE > contiguous birth=443448 fill=298 > cksum=8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac Ok, the offsets are definately up there... What is your normal installation? 8.0 i386? robert. -- Robert Noland FreeBSD From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 16:46:12 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D71A4106568B; Wed, 18 Nov 2009 16:46:12 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 430148FC18; Wed, 18 Nov 2009 16:46:12 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 0501D244; Wed, 18 Nov 2009 17:50:14 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 17:46:06 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: In-Reply-To: <1258562628.2303.83.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:46:12 -0000 On Wed, 18 Nov 2009 17:43:48 +0100, Robert Noland wrote: > On Wed, 2009-11-18 at 17:11 +0100, Emil Smolenski wrote: >> On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland >> wrote: >> >> >> >> Should I file a PR? I would >> >> >> like to help in debugging it (however my skills in low-level C >> aren't >> >> >> strong enough to do it on my own). >> >> > Ok, the first thing I would like to see is "zdb -uuu". >> >> # zdb -uuu pgpool >> >> Segmentation fault: 11 (core dumped) >> >> > Ok, this is disturbing... It works fine for me on -CURRENT / amd64 >> and >> > reports the root block pointer, which is what we need to locate the >> MOS. >> >> Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb >> -uuu" >> happy: >> >> Fixit# zdb -uuu pgpool >> Uberblock >> >> magic = 0000000000bab10c >> version = 13 >> txg = 443448 >> guid_sum = 9780688847620645377 >> timestamp = 1258560175 UTC = Wed Nov 18 16:02:55 2009 >> rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:220000de400:200> >> DVA[1]=<0:2a80008ee00:200> DVA[2]=<0:330000b9000:200> fletcher4 lzjb LE >> contiguous birth=443448 fill=298 >> cksum=8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac > > Ok, the offsets are definately up there... What is your normal > installation? 8.0 i386? 7.2-STABLE, amd64. -- am From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 18:54:09 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89BF7106568F; Wed, 18 Nov 2009 18:54:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 625FE8FC18; Wed, 18 Nov 2009 18:54:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAIIs9oX079915; Wed, 18 Nov 2009 18:54:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAIIs9Rq079911; Wed, 18 Nov 2009 18:54:09 GMT (envelope-from linimon) Date: Wed, 18 Nov 2009 18:54:09 GMT Message-Id: <200911181854.nAIIs9Rq079911@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140661: [zfs] /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:54:09 -0000 Old Synopsis: /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 New Synopsis: [zfs] /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 18 18:53:38 UTC 2009 Responsible-Changed-Why: This may not be amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=140661 From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 21:00:08 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6804610656A3 for ; Wed, 18 Nov 2009 21:00:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1008FC0A for ; Wed, 18 Nov 2009 21:00:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAIL08qk082774 for ; Wed, 18 Nov 2009 21:00:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAIL089D082773; Wed, 18 Nov 2009 21:00:08 GMT (envelope-from gnats) Date: Wed, 18 Nov 2009 21:00:08 GMT Message-Id: <200911182100.nAIL089D082773@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Scot Hetzel Cc: Subject: Re: amd64/140661: /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scot Hetzel List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:00:08 -0000 The following reply was made to PR kern/140661; it has been noted by GNATS. From: Scot Hetzel To: Kenneth Vestergaard Schmidt Cc: freebsd-gnats-submit@freebsd.org Subject: Re: amd64/140661: /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 Date: Wed, 18 Nov 2009 14:57:19 -0600 On 11/18/09, Kenneth Vestergaard Schmidt wrote: > Two machines tested, and both fail. Both installed according to > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot but one of them with an added > disk in a mirror. > > Both installed and working as 8.0-RC1. Both fail after upgrading to 8.0-RC2, > and ditto when trying 8.0-RC3. > > Upon booting, the following messages are visible just prior to an automatic > reboot: > > Can't work out which disk we are booting from. > Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0: > ficl-s not found > Assertion failed: (FALSE), function ficlCompileSoftCore, file softcore.c, > line 428. > > /boot/loader.conf contains: > zfs_load="YES" > vfs.root.mountfrom="zfs:pil" > > mckusick# zpool get bootfs pil > NAME PROPERTY VALUE SOURCE > pil bootfs pil local > I recently installed FreeBSD 8.0-RC3 on a new system using the same steps as mentioned in the above guide, and I didn't have any problem booting FreeBSD 8.0-RC3 with the /boot/loader that was created in step 2.6 Install ZFS aware /boot/loader. dv8t01# uname -a FreeBSD dv8t01 8.0-RC3 FreeBSD 8.0-RC3 #0: Tue Nov 10 06:35:19 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 dv8t01# grep zfs /boot/loader.conf vfs.root.mountfrom="zfs:zroot" zfs_load="YES" dv8t01# zpool get bootfs zroot NAME PROPERTY VALUE SOURCE zroot bootfs zroot local Make sure you have LOADER_ZFS_SUPPORT in your /etc/src.conf: dv8t01# cat /etc/src.conf LOADER_ZFS_SUPPORT=YES Scot From owner-freebsd-fs@FreeBSD.ORG Wed Nov 18 23:48:05 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E26A1065697; Wed, 18 Nov 2009 23:48:05 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by mx1.freebsd.org (Postfix) with ESMTP id DA4D08FC12; Wed, 18 Nov 2009 23:48:04 +0000 (UTC) Received: by ywh8 with SMTP id 8so1614197ywh.3 for ; Wed, 18 Nov 2009 15:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/44jw8zlKKtLGe85/WV4F5SWRkjeSOlRfGuQdX9hl2E=; b=iD4mn9Xlim6XA2MyYBpqvHEpcFpajRVQQ3trStZQRB+otwkiWOUNI/qZbSSb+t6CEp v8kEBnd6QaIvoGVTVt6W+4j8TFwkA2hZdZJXBwzixQtMJ2AS0mTMwFsC9OORl46R8vek ejA8j18QHKA4WNH9eL7pYNUBhnCg1HsdnpqZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mDNkwi3o6PVuHqI/pkiJrO5ZQ9EY/NZuSrriDnFpuNhin0SgzLcvpG7ibeiInnfYQl STpR0HnRDncR/L29PYfkJwUEz8oznnijUqOxH8rL74HhIQB9TYTXzDAycrALgJZokMAb IQTFj+gKjAB15e3h2AYQZoxODqnTVk2i8cBZI= MIME-Version: 1.0 Received: by 10.150.130.24 with SMTP id c24mr3474103ybd.168.1258588083989; Wed, 18 Nov 2009 15:48:03 -0800 (PST) In-Reply-To: <1258562628.2303.83.camel@balrog.2hip.net> References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> Date: Wed, 18 Nov 2009 15:48:03 -0800 Message-ID: From: Matt Reimer To: Emil Smolenski Content-Type: multipart/mixed; boundary=000e0cd5a01aaa2bdf0478addf54 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Robert Noland Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:48:05 -0000 --000e0cd5a01aaa2bdf0478addf54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 18, 2009 at 8:43 AM, Robert Noland wrote: > On Wed, 2009-11-18 at 17:11 +0100, Emil Smolenski wrote: >> On Wed, 18 Nov 2009 14:50:47 +0100, Robert Noland >> wrote: >> >> >> >> Should I file a PR? I would >> >> >> like to help in debugging it (however my skills in low-level C are= n't >> >> >> strong enough to do it on my own). >> >> > Ok, the first thing I would like to see is "zdb -uuu". >> >> # zdb -uuu pgpool >> >> Segmentation fault: 11 (core dumped) >> >> > Ok, this is disturbing... =A0It works fine for me on -CURRENT / amd64 = and >> > reports the root block pointer, which is what we need to locate the MO= S. >> >> =A0 Booting from 8.0-*-amd64-memstick.img (Fixit# console) makes "zdb -u= uu" >> happy: >> >> Fixit# zdb -uuu pgpool >> Uberblock >> >> =A0 =A0 =A0 =A0 =A0magic =3D 0000000000bab10c >> =A0 =A0 =A0 =A0 =A0version =3D 13 >> =A0 =A0 =A0 =A0 =A0txg =3D 443448 >> =A0 =A0 =A0 =A0 =A0guid_sum =3D 9780688847620645377 >> =A0 =A0 =A0 =A0 =A0timestamp =3D 1258560175 UTC =3D Wed Nov 18 16:02:55 = 2009 >> =A0 =A0 =A0 =A0 =A0rootbp =3D [L0 DMU objset] 400L/200P DVA[0]=3D<0:2200= 00de400:200> >> DVA[1]=3D<0:2a80008ee00:200> DVA[2]=3D<0:330000b9000:200> fletcher4 lzjb= LE >> contiguous birth=3D443448 fill=3D298 >> cksum=3D8a9775385:3935d6d58c7:c028430c00a8:1b58ac4ebf42ac > > Ok, the offsets are definately up there... What is your normal > installation? =A08.0 i386? Robert's on to something. It looks like your LBAs are probably overflowing 32 bits. This would affect all vdev regardless of type. Try the attached patch. Matt --000e0cd5a01aaa2bdf0478addf54 Content-Type: application/octet-stream; name="zfsboot.c.patch3" Content-Disposition: attachment; filename="zfsboot.c.patch3" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g26qtvfe0 LS0tIGkzODYvemZzYm9vdC96ZnNib290LmMub3JpZwkyMDA5LTEwLTI0IDE4OjEwOjI5LjAwMDAw MDAwMCAtMDcwMAorKysgaTM4Ni96ZnNib290L3pmc2Jvb3QuYwkyMDA5LTExLTE4IDE1OjM2OjM0 LjAwMDAwMDAwMCAtMDgwMApAQCAtMTYzLDcgKzE2Myw3IEBACiBzdGF0aWMgdm9pZCBwcmludGYo Y29uc3QgY2hhciAqLC4uLik7CiBzdGF0aWMgdm9pZCBwdXRjaGFyKGludCk7CiBzdGF0aWMgdWlu dDMyX3QgbWVtc2l6ZSh2b2lkKTsKLXN0YXRpYyBpbnQgZHJ2cmVhZChzdHJ1Y3QgZHNrICosIHZv aWQgKiwgdW5zaWduZWQsIHVuc2lnbmVkKTsKK3N0YXRpYyBpbnQgZHJ2cmVhZChzdHJ1Y3QgZHNr ICosIHZvaWQgKiwgdWludDY0X3QsIHVuc2lnbmVkKTsKIHN0YXRpYyBpbnQga2V5aGl0KHVuc2ln bmVkKTsKIHN0YXRpYyBpbnQgeHB1dGMoaW50KTsKIHN0YXRpYyBpbnQgeGdldGMoaW50KTsKQEAg LTMxMCw3ICszMTEsOCBAQAogdmRldl9yZWFkKHZkZXZfdCAqdmRldiwgdm9pZCAqcHJpdiwgb2Zm X3Qgb2ZmLCB2b2lkICpidWYsIHNpemVfdCBieXRlcykKIHsKIAljaGFyICpwOwotCXVuc2lnbmVk IGludCBsYmEsIG5iOworCXVpbnQ2NF90IGxiYTsKKwl1bnNpZ25lZCBpbnQgbmI7CiAJc3RydWN0 IGRzayAqZHNrID0gKHN0cnVjdCBkc2sgKikgcHJpdjsKIAogCWlmICgob2ZmICYgKERFVl9CU0la RSAtIDEpKSB8fCAoYnl0ZXMgJiAoREVWX0JTSVpFIC0gMSkpKQpAQCAtOTQ5LDcgKzk1MSw3IEBA CiAjZW5kaWYKIAogc3RhdGljIGludAotZHJ2cmVhZChzdHJ1Y3QgZHNrICpkc2ssIHZvaWQgKmJ1 ZiwgdW5zaWduZWQgbGJhLCB1bnNpZ25lZCBuYmxrKQorZHJ2cmVhZChzdHJ1Y3QgZHNrICpkc2ss IHZvaWQgKmJ1ZiwgdWludDY0X3QgbGJhLCB1bnNpZ25lZCBuYmxrKQogewogI2lmZGVmIEdQVAog ICAgIHN0YXRpYyB1bnNpZ25lZCBjID0gMHgyZDVjN2MyZjsK --000e0cd5a01aaa2bdf0478addf54-- From owner-freebsd-fs@FreeBSD.ORG Thu Nov 19 02:26:59 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 071E7106566B; Thu, 19 Nov 2009 02:26:59 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D2D168FC18; Thu, 19 Nov 2009 02:26:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAJ2Qv8s066421; Thu, 19 Nov 2009 02:26:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAJ2QvBN066417; Thu, 19 Nov 2009 02:26:57 GMT (envelope-from linimon) Date: Thu, 19 Nov 2009 02:26:57 GMT Message-Id: <200911190226.nAJ2QvBN066417@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140682: [netgraph] [panic] random panic in netgraph X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 02:26:59 -0000 Old Synopsis: randomly panic New Synopsis: [netgraph] [panic] random panic in netgraph Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 19 02:25:02 UTC 2009 Responsible-Changed-Why: looks like this might be netgraph-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=140682 From owner-freebsd-fs@FreeBSD.ORG Thu Nov 19 02:40:03 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1AC61065672 for ; Thu, 19 Nov 2009 02:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7692B8FC13 for ; Thu, 19 Nov 2009 02:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAJ2e3Ow076224 for ; Thu, 19 Nov 2009 02:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAJ2e3sk076223; Thu, 19 Nov 2009 02:40:03 GMT (envelope-from gnats) Date: Thu, 19 Nov 2009 02:40:03 GMT Message-Id: <200911190240.nAJ2e3sk076223@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Nathaniel Filardo Cc: Subject: Re: kern/139725: [zfs] zdb(1) dumps core on i386 when examining zpool contents: Assertion failed: (rwlp->rw_count == 0) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nathaniel Filardo List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 02:40:03 -0000 The following reply was made to PR kern/139725; it has been noted by GNATS. From: Nathaniel Filardo To: bug-followup@FreeBSD.org, henno@schooljan.nl Cc: Subject: Re: kern/139725: [zfs] zdb(1) dumps core on i386 when examining zpool contents: Assertion failed: (rwlp->rw_count == 0) Date: Wed, 18 Nov 2009 21:14:48 -0500 This is not an i386 specific thing; I am able to reproduce it readily on my SPARC64 machine, and can make core files available if they'd help. Thanks! --nwf; From owner-freebsd-fs@FreeBSD.ORG Thu Nov 19 03:57:55 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B90106566B; Thu, 19 Nov 2009 03:57:55 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA178FC08; Thu, 19 Nov 2009 03:57:54 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-213-186.bna.bellsouth.net [68.19.213.186]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAJ3vgRV022203 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Nov 2009 22:57:45 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Matt Reimer In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Wed, 18 Nov 2009 21:57:37 -0600 Message-Id: <1258603057.2303.92.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Emil Smolenski Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 03:57:55 -0000 On Wed, 2009-11-18 at 15:48 -0800, Matt Reimer wrote: > 220000de400 This divided by 512 byte block size is 33 bits... At a glance, the patch looks ok to me. I'll do a more thorough review of this tomorrow. robert. -- Robert Noland FreeBSD From owner-freebsd-fs@FreeBSD.ORG Thu Nov 19 10:21:31 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1070B1065676; Thu, 19 Nov 2009 10:21:31 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id A24098FC18; Thu, 19 Nov 2009 10:21:30 +0000 (UTC) Received: from am-laptop.local.org (gpx218.internetdsl.tpnet.pl [83.3.153.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id 835091D7; Thu, 19 Nov 2009 11:25:33 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" , "Matt Reimer" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> <1258603057.2303.92.camel@balrog.2hip.net> Date: Thu, 19 Nov 2009 11:21:24 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Emil Smolenski" Organization: Cadera Sp. z o.o. Message-ID: In-Reply-To: <1258603057.2303.92.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:21:31 -0000 Matt Reimer wrote: > Robert's on to something. It looks like your LBAs are probably > overflowing 32 bits. This would affect all vdev regardless of type. > Try the attached patch. Robert Noland wrote: >> 220000de400 > This divided by 512 byte block size is 33 bits... At a glance, the patch > looks ok to me. I'll do a more thorough review of this tomorrow. Unfortunately it don't work. Error is the same as before: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS ZFS: unexpected object set type 0 ZFS: unexpected object set type 0 FreeBSD/i386 boot Default: pgpool:/boot/kernel/kernel boot: ZFS: unexpected object set type 0 This is 7.2-STABLE, amd64. My test procedure: 1. I fully synchronized these zfsboot-related directories with -CURRENT: src/sys/boot/i386/zfsboot src/sys/boot/zfs src/sys/cddl/boot/zfs 2. I applied Matt Reimer's zfsboot.c.patch3 patch: # cd /usr/src/sys/boot/ # patch < /path/to/zfsboot.c.patch3 3. Then I did: # make clean; make cleandir # make obj ; make depend ; make # cd i386/loader # make install # cd /usr/src/sys/boot/i386/zfsboot # make install # sysctl kern.geom.debugflags=16 # dd if=/boot/zfsboot of=/dev/da0 count=1 # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 # reboot 4. Result: error shown above. Thanks! -- am From owner-freebsd-fs@FreeBSD.ORG Thu Nov 19 16:24:04 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21272106568B; Thu, 19 Nov 2009 16:24:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D403C8FC16; Thu, 19 Nov 2009 16:24:03 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-218-170.ard.bellsouth.net [72.154.218.170]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nAJGO0MG026150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 11:24:01 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Emil Smolenski In-Reply-To: References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> <1258603057.2303.92.camel@balrog.2hip.net> Content-Type: multipart/mixed; boundary="=-BDiV+OcYAkHUcmXfsTdc" Organization: FreeBSD Date: Thu, 19 Nov 2009 10:23:55 -0600 Message-Id: <1258647835.2303.105.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:24:04 -0000 --=-BDiV+OcYAkHUcmXfsTdc Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2009-11-19 at 11:21 +0100, Emil Smolenski wrote: > Matt Reimer wrote: > > Robert's on to something. It looks like your LBAs are probably > > overflowing 32 bits. This would affect all vdev regardless of type. > > Try the attached patch. > > Robert Noland wrote: > >> 220000de400 > > This divided by 512 byte block size is 33 bits... At a glance, the patch > > looks ok to me. I'll do a more thorough review of this tomorrow. > > Unfortunately it don't work. Error is the same as before: Ok, I was concerned about the assembly code... So, I've been chatting with jhb@ this morning. Please try this patch that jhb@ came up with instead of Matt's latest patch. robert. > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > ZFS: unexpected object set type 0 > ZFS: unexpected object set type 0 > > FreeBSD/i386 boot > Default: pgpool:/boot/kernel/kernel > boot: > ZFS: unexpected object set type 0 > > > This is 7.2-STABLE, amd64. My test procedure: > > 1. I fully synchronized these zfsboot-related directories with -CURRENT: > > src/sys/boot/i386/zfsboot > src/sys/boot/zfs > src/sys/cddl/boot/zfs > > 2. I applied Matt Reimer's zfsboot.c.patch3 patch: > > # cd /usr/src/sys/boot/ > # patch < /path/to/zfsboot.c.patch3 > > 3. Then I did: > > # make clean; make cleandir > # make obj ; make depend ; make > # cd i386/loader > # make install > # cd /usr/src/sys/boot/i386/zfsboot > # make install > # sysctl kern.geom.debugflags=16 > # dd if=/boot/zfsboot of=/dev/da0 count=1 > # dd if=/boot/zfsboot of=/dev/da0 skip=1 seek=1024 > # reboot > > 4. Result: error shown above. > > Thanks! > -- Robert Noland FreeBSD --=-BDiV+OcYAkHUcmXfsTdc Content-Disposition: attachment; filename="zfsboot_64.patch" Content-Type: text/x-patch; name="zfsboot_64.patch"; charset="us-ascii" Content-Transfer-Encoding: 7bit --- //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsboot.c +++ /home/jhb/work/p4/boot/sys/boot/i386/zfsboot/zfsboot.c @@ -138,8 +138,8 @@ unsigned unit; unsigned slice; unsigned part; - unsigned start; int init; + daddr_t start; }; static char cmd[512]; static char kname[1024]; @@ -163,7 +163,7 @@ static void printf(const char *,...); static void putchar(int); static uint32_t memsize(void); -static int drvread(struct dsk *, void *, unsigned, unsigned); +static int drvread(struct dsk *, void *, daddr_t, unsigned); static int keyhit(unsigned); static int xputc(int); static int xgetc(int); @@ -310,7 +310,8 @@ vdev_read(vdev_t *vdev, void *priv, off_t off, void *buf, size_t bytes) { char *p; - unsigned int lba, nb; + daddr_t lba; + unsigned int nb; struct dsk *dsk = (struct dsk *) priv; if ((off & (DEV_BSIZE - 1)) || (bytes & (DEV_BSIZE - 1))) @@ -964,7 +965,7 @@ #endif static int -drvread(struct dsk *dsk, void *buf, unsigned lba, unsigned nblk) +drvread(struct dsk *dsk, void *buf, daddr_t lba, unsigned nblk) { #ifdef GPT static unsigned c = 0x2d5c7c2f; @@ -999,7 +1000,7 @@ v86.es = VTOPSEG(buf); v86.eax = lba; v86.ebx = VTOPOFF(buf); - v86.ecx = lba >> 16; + v86.ecx = lba >> 32; v86.edx = nblk << 8 | dsk->drive; v86int(); v86.ctl = V86_FLAGS; --- //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsldr.S +++ /home/jhb/work/p4/boot/sys/boot/i386/zfsboot/zfsldr.S @@ -80,10 +80,10 @@ .org 0x25,0x90 /* - * Trampoline used by boot2 to call read to read data from the disk via + * Trampoline used by zfsboot to call read to read data from the disk via * the BIOS. Call with: * - * %cx:%ax - long - LBA to read in + * %ecx:%eax - long - LBA to read in * %es:(%bx) - caddr_t - buffer to read data into * %dl - byte - drive to read from * %dh - byte - num sectors to read @@ -94,10 +94,8 @@ /* * Setup an EDD disk packet and pass it to read */ -xread.1: # Starting - pushl $0x0 # absolute - push %cx # block - push %ax # number +xread.1: pushl %ecx # Starting absolute block + pushl %eax # block number push %es # Address of push %bx # transfer buffer xor %ax,%ax # Number of @@ -245,10 +243,11 @@ /* * Trampoline used to call read from within boot1. */ -nread: xor %ax,%ax # Sector offset in partition +nread: xor %eax,%eax # Sector offset in partition nread.1: mov $MEM_BUF,%bx # Transfer buffer - add 0x8(%si),%ax # Get - mov 0xa(%si),%cx # LBA + xor %ecx,%ecx # Get + addl 0x8(%si),%eax # LBA + adc $0,%ecx push %cs # Read from callw xread.1 # disk jnc return # If success, return --=-BDiV+OcYAkHUcmXfsTdc-- From owner-freebsd-fs@FreeBSD.ORG Thu Nov 19 17:02:39 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AEB91065695; Thu, 19 Nov 2009 17:02:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D94808FC29; Thu, 19 Nov 2009 17:02:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7709B46B2C; Thu, 19 Nov 2009 12:02:38 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id BA4928A020; Thu, 19 Nov 2009 12:02:37 -0500 (EST) From: John Baldwin To: freebsd-fs@freebsd.org Date: Thu, 19 Nov 2009 11:55:10 -0500 User-Agent: KMail/1.9.7 References: <1258647835.2303.105.camel@balrog.2hip.net> In-Reply-To: <1258647835.2303.105.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_uhXBLdyw4w+BTUK" Message-Id: <200911191155.10490.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Nov 2009 12:02:37 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Emil Smolenski , Robert Noland Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:02:39 -0000 --Boundary-00=_uhXBLdyw4w+BTUK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 19 November 2009 11:23:55 am Robert Noland wrote: > On Thu, 2009-11-19 at 11:21 +0100, Emil Smolenski wrote: > > Matt Reimer wrote: > > > Robert's on to something. It looks like your LBAs are probably > > > overflowing 32 bits. This would affect all vdev regardless of type. > > > Try the attached patch. > > > > Robert Noland wrote: > > >> 220000de400 > > > This divided by 512 byte block size is 33 bits... At a glance, the patch > > > looks ok to me. I'll do a more thorough review of this tomorrow. > > > > Unfortunately it don't work. Error is the same as before: > > Ok, I was concerned about the assembly code... So, I've been chatting > with jhb@ this morning. Please try this patch that jhb@ came up with > instead of Matt's latest patch. Actually, I had missed updating one place, please use this instead. Also, I think that this will fix using > 2TB volumes even in the GPT case as zfsboot.c was always using 32-bit LBAs even for the GPT case. -- John Baldwin --Boundary-00=_uhXBLdyw4w+BTUK Content-Type: text/x-diff; charset="iso-8859-1"; name="zfsboot_64.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfsboot_64.patch" --- //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsboot.c +++ /home/jhb/work/p4/boot/sys/boot/i386/zfsboot/zfsboot.c @@ -138,8 +138,8 @@ unsigned unit; unsigned slice; unsigned part; - unsigned start; int init; + daddr_t start; }; static char cmd[512]; static char kname[1024]; @@ -163,7 +163,7 @@ static void printf(const char *,...); static void putchar(int); static uint32_t memsize(void); -static int drvread(struct dsk *, void *, unsigned, unsigned); +static int drvread(struct dsk *, void *, daddr_t, unsigned); static int keyhit(unsigned); static int xputc(int); static int xgetc(int); @@ -310,7 +310,8 @@ vdev_read(vdev_t *vdev, void *priv, off_t off, void *buf, size_t bytes) { char *p; - unsigned int lba, nb; + daddr_t lba; + unsigned int nb; struct dsk *dsk = (struct dsk *) priv; if ((off & (DEV_BSIZE - 1)) || (bytes & (DEV_BSIZE - 1))) @@ -964,7 +965,7 @@ #endif static int -drvread(struct dsk *dsk, void *buf, unsigned lba, unsigned nblk) +drvread(struct dsk *dsk, void *buf, daddr_t lba, unsigned nblk) { #ifdef GPT static unsigned c = 0x2d5c7c2f; @@ -999,7 +1000,7 @@ v86.es = VTOPSEG(buf); v86.eax = lba; v86.ebx = VTOPOFF(buf); - v86.ecx = lba >> 16; + v86.ecx = lba >> 32; v86.edx = nblk << 8 | dsk->drive; v86int(); v86.ctl = V86_FLAGS; --- //depot/vendor/freebsd/src/sys/boot/i386/zfsboot/zfsldr.S 2008/11/17 20:55:47 +++ //depot/user/jhb/boot/sys/boot/i386/zfsboot/zfsldr.S 2009/11/19 16:53:18 @@ -83,7 +83,7 @@ * Trampoline used by boot2 to call read to read data from the disk via * the BIOS. Call with: * - * %cx:%ax - long - LBA to read in + * %ecx:%eax - long - LBA to read in * %es:(%bx) - caddr_t - buffer to read data into * %dl - byte - drive to read from * %dh - byte - num sectors to read @@ -94,10 +94,8 @@ /* * Setup an EDD disk packet and pass it to read */ -xread.1: # Starting - pushl $0x0 # absolute - push %cx # block - push %ax # number +xread.1: pushl %ecx # Starting absolute block + pushl %eax # block number push %es # Address of push %bx # transfer buffer xor %ax,%ax # Number of @@ -195,7 +193,7 @@ */ main.5: mov %dx,MEM_ARG # Save args movb $NSECT,%dh # Sector count - movw $1024,%ax # Offset to boot2 + movl $1024,%eax # Offset to boot2 callw nread.1 # Read disk main.6: mov $MEM_BUF,%si # BTX (before reloc) mov 0xa(%si),%bx # Get BTX length and set @@ -245,10 +243,11 @@ /* * Trampoline used to call read from within boot1. */ -nread: xor %ax,%ax # Sector offset in partition +nread: xor %eax,%eax # Sector offset in partition nread.1: mov $MEM_BUF,%bx # Transfer buffer - add 0x8(%si),%ax # Get - mov 0xa(%si),%cx # LBA + xor %ecx,%ecx # Get + addl 0x8(%si),%eax # LBA + adc $0,%ecx push %cs # Read from callw xread.1 # disk jnc return # If success, return --Boundary-00=_uhXBLdyw4w+BTUK-- From owner-freebsd-fs@FreeBSD.ORG Thu Nov 19 23:04:14 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACEB01065697; Thu, 19 Nov 2009 23:04:14 +0000 (UTC) (envelope-from ambsd@raisa.eu.org) Received: from raisa.eu.org (raisa.eu.org [83.17.178.202]) by mx1.freebsd.org (Postfix) with ESMTP id 3B08C8FC14; Thu, 19 Nov 2009 23:04:14 +0000 (UTC) Received: from bolt.zol (62-121-98-25.home.aster.pl [62.121.98.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by raisa.eu.org (Postfix) with ESMTP id C95E628; Fri, 20 Nov 2009 00:08:16 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Robert Noland" , "John Baldwin" References: <1258390784.2303.42.camel@balrog.2hip.net> <1258497221.2303.66.camel@balrog.2hip.net> <1258552247.2303.75.camel@balrog.2hip.net> <1258562628.2303.83.camel@balrog.2hip.net> <1258603057.2303.92.camel@balrog.2hip.net> <1258647835.2303.105.camel@balrog.2hip.net> Date: Fri, 20 Nov 2009 00:04:16 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Emil Smolenski" Message-ID: In-Reply-To: <1258647835.2303.105.camel@balrog.2hip.net> User-Agent: Opera Mail/10.01 (FreeBSD) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 23:04:14 -0000 On Thu, 19 Nov 2009 17:23:55 +0100, Robert Noland wrote: > Ok, I was concerned about the assembly code... So, I've been chatting > with jhb@ this morning. Please try this patch that jhb@ came up with > instead of Matt's latest patch. On Thu, 19 Nov 2009 17:55:10 +0100, John Baldwin wrote: > Actually, I had missed updating one place, please use this instead. > Also, I > think that this will fix using > 2TB volumes even in the GPT case as > zfsboot.c was always using 32-bit LBAs even for the GPT case. Thanks a million! Both patches works for me. Great work! I know that we have missed the boat but maybe there is opportunity to catch it up by swimming and commit these patches to 8-STABLE before 8.0-RELEASE? Thanks! -- am From owner-freebsd-fs@FreeBSD.ORG Fri Nov 20 02:48:07 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02E511065676 for ; Fri, 20 Nov 2009 02:48:07 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D731B8FC0A for ; Fri, 20 Nov 2009 02:48:06 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBJXZ-0003KQ-O3 for freebsd-fs@freebsd.org; Fri, 20 Nov 2009 02:48:06 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 372352C23097 for ; Fri, 20 Nov 2009 11:48:05 +0900 (JST) Date: Fri, 20 Nov 2009 11:48:05 +0900 Message-ID: From: Randy Bush To: FreeBSD FileSys List User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 02:48:07 -0000 i think the issue is how to tune for zfs i386 with 4G of RAM FreeBSD psg.com 7.2-STABLE FreeBSD 7.2-STABLE #2: Wed Nov 18 03:04:55 GMT 2009 root@psg.com:/usr/obj/usr/src/sys/PSG i386 RELENG_7 cvsupped Nov 18 02:42 GMT panic: kmem_malloc(65536): kmem_map too small: 535019520 total allocated cpuid = 0 Uptime: 13h15m1s Physical memory: 3958 MB Dumping 637 MB: 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort and it did not auto reboot # cat /boot/loader.conf.local ipfw_load=YES umass_load=YES zfs_load=YES vm.kmem_size=536870912 vm.kmem_size_max=1073741824 vfs.zfs.prefetch_disable=1 it has zfs # zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 twed1 ONLINE 0 0 0 twed2 ONLINE 0 0 0 errors: No known data errors but boots and has root on ufs # df -H Filesystem Size Used Avail Capacity Mounted on /dev/twed0s1a 260M 199M 40M 83% / devfs 1.0k 1.0k 0B 100% /dev /dev/twed0s1h 65M 2.3M 57M 4% /root procfs 4.1k 4.1k 0B 100% /proc tank 147G 17M 147G 0% /tank tank/usr 167G 20G 147G 12% /usr tank/usr/home 216G 68G 147G 32% /usr/home tank/var 149G 2.3G 147G 2% /var tank/var/spool 148G 531M 147G 0% /var/spool /dev/md0 130M 12k 119M 0% /tmp # kgdb kernel.debug /usr/home/crash/vmcore.20 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: kmem_malloc(65536): kmem_map too small: 535019520 total allocated cpuid = 0 Uptime: 13h15m1s Physical memory: 3958 MB Dumping 637 MB: 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko Reading symbols from /boot/kernel/cam.ko...Reading symbols from /boot/kernel/cam.ko.symbols...done. done. Loaded symbols for /boot/kernel/cam.ko Reading symbols from /boot/kernel/usb.ko...Reading symbols from /boot/kernel/usb.ko.symbols...done. done. Loaded symbols for /boot/kernel/usb.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) back #0 doadump () at pcpu.h:196 #1 0xc052b0b6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc052b39e in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06dfb54 in kmem_malloc (map=0xc107108c, size=65536, flags=2) at /usr/src/sys/vm/vm_kern.c:305 #4 0xc06d6317 in page_alloc (zone=0x0, bytes=65536, pflag=0xf67ee4a7 "\002", wait=2) at /usr/src/sys/vm/uma_core.c:952 #5 0xc06d8e20 in uma_large_malloc (size=65536, wait=2) at /usr/src/sys/vm/uma_core.c:2706 #6 0xc05189e8 in malloc (size=65536, mtp=0xc0989060, flags=2) at /usr/src/sys/kern/kern_malloc.c:393 #7 0xc0897a61 in zfs_kmem_alloc (size=65536, kmflags=2) at /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:74 #8 0xc090bf4a in zio_buf_alloc (size=65536) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:207 #9 0xc08f3472 in vdev_cache_read (zio=0xd39d0708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_cache.c:188 #10 0xc090c145 in zio_vdev_io_start (zio=0xd39d0708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1816 #11 0xc090c7f0 in zio_execute (zio=0xd39d0708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #12 0xc08f6bda in vdev_mirror_io_start (zio=0xd77e7708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:303 #13 0xc090c7f0 in zio_execute (zio=0xd77e7708) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #14 0xc08f6bda in vdev_mirror_io_start (zio=0xdbd22960) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:303 #15 0xc090c7f0 in zio_execute (zio=0xdbd22960) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:998 #16 0xc08ad39d in arc_read_nolock (pio=0xd1844960, spa=0xc7746000, bp=0xcc548640, done=0xc08b0600 , private=0xd9c89e38, priority=0, zio_flags=1, arc_flags=0xf67ee854, zb=0xf67ee834) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2762 #17 0xc08ad878 in arc_read (pio=0xd1844960, spa=0xc7746000, bp=0xcc548640, pbuf=0xc9b29134, done=0xc08b0600 , private=0xd9c89e38, priority=0, zio_flags=1, arc_flags=0xf67ee854, zb=0xf67ee834) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2507 #18 0xc08b0ada in dbuf_read (db=0xd9c89e38, zio=0xd1844960, flags=14) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:521 #19 0xc08b1142 in dbuf_findbp (dn=0xcba92000, level=Variable "level" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1381 #20 0xc08b1269 in dbuf_hold_impl (dn=0xcba92000, level=0 '\0', blkid=0, fail_sparse=0, tag=0x0, dbp=0xf67ee8f0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1617 #21 0xc08b2529 in dbuf_hold (dn=0xcba92000, blkid=0, tag=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1689 #22 0xc08b48cc in dmu_buf_hold (os=0xc774b3d0, object=167123, offset=0, tag=0x0, dbp=0xf67ee95c) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:101 #23 0xc0900044 in zap_lockdir (os=0xc774b3d0, obj=167123, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=0xf67eeba0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:388 #24 0xc09009fd in zap_cursor_retrieve (zc=0xf67eeb9c, za=0xf67eea84) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1004 #25 0xc0925a2b in zfs_freebsd_readdir (ap=0xf67eec00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2156 #26 0xc07382f2 in VOP_READDIR_APV (vop=0xc098b560, a=0xf67eec00) at vnode_if.c:1407 #27 0xc05becae in kern_getdirentries (td=0xd5a01000, fd=19, buf=0x29061000
, count=4096, basep=0xf67eec74) at vnode_if.h:747 #28 0xc05beec1 in getdirentries (td=0xd5a01000, uap=0xf67eecfc) at /usr/src/sys/kern/vfs_syscalls.c:3776 #29 0xc072cfc5 in syscall (frame=0xf67eed38) at /usr/src/sys/i386/i386/trap.c:1101 #30 0xc0711380 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #31 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) randy From owner-freebsd-fs@FreeBSD.ORG Fri Nov 20 10:01:58 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FCAF106566C for ; Fri, 20 Nov 2009 10:01:58 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BAFFD8FC1A for ; Fri, 20 Nov 2009 10:01:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBQJP-0004MN-LC for freebsd-fs@freebsd.org; Fri, 20 Nov 2009 10:01:56 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id EC1112C2479B for ; Fri, 20 Nov 2009 19:01:54 +0900 (JST) Date: Fri, 20 Nov 2009 19:01:54 +0900 Message-ID: From: Randy Bush To: FreeBSD FileSys List In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 10:01:58 -0000 it was pointed out that i did not include my kernel config. so here you go. # egrep -v '^(#|$)' /sys/i386/conf/PSG cpu I686_CPU ident PSG makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KVA_PAGES=512 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC device cpufreq device pci device fdc device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering device twe # 3ware ATA RAID device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver device ppc device ppbus # Parallel port bus (required) device em # Intel PRO/1000 Gigabit Ethernet Family device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device firmware # firmware assist module device bpf # Berkeley packet filter randy From owner-freebsd-fs@FreeBSD.ORG Fri Nov 20 14:41:38 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7767B106566B; Fri, 20 Nov 2009 14:41:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 47D908FC0A; Fri, 20 Nov 2009 14:41:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0569046B0D; Fri, 20 Nov 2009 09:41:38 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 364398A01D; Fri, 20 Nov 2009 09:41:37 -0500 (EST) From: John Baldwin To: "Emil Smolenski" Date: Fri, 20 Nov 2009 07:43:51 -0500 User-Agent: KMail/1.9.7 References: <1258647835.2303.105.camel@balrog.2hip.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911200743.52233.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 20 Nov 2009 09:41:37 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Robert Noland Subject: Re: Boot with ZFS on single disk: "ZFS: i/o error - all block copies unavailable" [was: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:41:38 -0000 On Thursday 19 November 2009 6:04:16 pm Emil Smolenski wrote: > On Thu, 19 Nov 2009 17:23:55 +0100, Robert Noland > wrote: > > Ok, I was concerned about the assembly code... So, I've been chatting > > with jhb@ this morning. Please try this patch that jhb@ came up with > > instead of Matt's latest patch. > > On Thu, 19 Nov 2009 17:55:10 +0100, John Baldwin wrote: > > Actually, I had missed updating one place, please use this instead. > > Also, I > > think that this will fix using > 2TB volumes even in the GPT case as > > zfsboot.c was always using 32-bit LBAs even for the GPT case. > > Thanks a million! Both patches works for me. Great work! > I know that we have missed the boat but maybe there is opportunity to > catch it up by swimming and commit these patches to 8-STABLE before > 8.0-RELEASE? Thanks! It is too late for 8.0 I'm afraid. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Sat Nov 21 00:46:55 2009 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 277A91065670 for ; Sat, 21 Nov 2009 00:46:55 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-px0-f196.google.com (mail-px0-f196.google.com [209.85.216.196]) by mx1.freebsd.org (Postfix) with ESMTP id F2DFD8FC13 for ; Sat, 21 Nov 2009 00:46:54 +0000 (UTC) Received: by pxi34 with SMTP id 34so2638169pxi.8 for ; Fri, 20 Nov 2009 16:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=4lxnM2Y2k0KxAYwwiipN/NGv7BHTwGgQ8po0ph4upG8=; b=OOtJy+URgIlCuzJ+XVXz34nOjytkUYhoG60EZokReUync0qPd8MmSIikKbynEgvNia 6iDxYCco4vtB5o1HhA5HL2ysuob4ammDd8OOnvsONOJbOZb/s1AufcDALXlclR59nXPf +f6E8qUwOgbB9SHsTL3hMUZzCuYsq6arkQKuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Cwl6aeLNqL+1IJieFpWi1PbZ4Cjo3FtVYW74sEvTBpi8lsYYJCSB/0d4MIwlSbVgne xv1AM4iEcInb513tuwIa3U2IPHR48ryRIl+P8FgtBit7NaYtzEs8yWTHaGkmWrVJROfm B22htwZd6fbyFtwyQ5FtUaFDgemK727ABLXT0= MIME-Version: 1.0 Received: by 10.142.1.22 with SMTP id 22mr228408wfa.340.1258764414665; Fri, 20 Nov 2009 16:46:54 -0800 (PST) Date: Fri, 20 Nov 2009 16:46:54 -0800 Message-ID: From: Matt Reimer To: fs@freebsd.org Content-Type: multipart/mixed; boundary=00504502b672cac4d00478d6ed9a Cc: Subject: Current gptzfsboot limitations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:46:55 -0000 --00504502b672cac4d00478d6ed9a Content-Type: text/plain; charset=ISO-8859-1 I've been analyzing gptzfsboot to see what its limitations are. I think it should now work fine for a healthy pool with any number of disks, with any type of vdev, whether single disk, stripe, mirror, raidz or raidz2. But there are currently several limitations (likely in loader.zfs too), mostly due to the limited amount of memory available (< 640KB) and the simple memory allocators used (a simple malloc() and zfs_alloc_temp()). 1. gptzfsboot might fail to read compressed files on raidz/raidz2 pools. The reason is that the temporary buffer used for I/O (zfs_temp_buf in zfsimpl.c) is 128KB by default, but a 128KB compressed block will require a 128KB buffer to be allocated before the I/O is done, leaving nothing for the raidz code further on. The fix would be to make more the temporary buffer larger, but for some reason it's not as simple as just changing the TEMP_SIZE define (possibly a stack overflow results; more debugging needed). Workaround: don't enable compression on your root filesystem (aka bootfs). 2. gptzfsboot might fail to reconstruct a file that is read from a degraded raidz/raidz2 pool, or if the file is corrupt somehow (i.e. the pool is healthy but the checksums don't match). The reason again is that the temporary buffer gets exhausted. I think this will only happen in the case where more than one physical block is corrupt or unreadable. The fix has several aspects: 1) make the temporary buffer much larger, perhaps larger than 640KB; 2) change zfssubr.c:vdev_raidz_read() to reuse the temp buffers it allocates when possible; and 3) either restructure zfssubr.c:vdev_raidz_reconstruct_pq() to only allocate its temporary buffers once per I/O, or use a malloc that has free() implemented. Workaround: repair your pool somehow (e.g. pxeboot) so one or no disks are bad. 3. gptzfsboot might fail to boot from a degraded pool that has one or more drives marked offline, removed, or faulted. The reason is that vdev_probe() assumes that all vdevs are healthy, regardless of their true state. gptzfsboot then will read from an offline/removed/faulted vdev as if it were healthy, likely resulting in failed checksums, resulting in the recovery code path being run in vdev_raidz_read(), possibly leading to zfs_temp_buf exhaustion as in #2 above. A partial patch for #3 is attached, but it is inadequate because it only reads a vdev's status from the first device's (in BIOS order) vdev_label, with the result that if the first device is marked offline, gptzfsboot won't see this because only the other devices' vdev_labels will indicate that the first device is offline. (Since after a device is offlined no further writes will be made to the device, its vdev_label is not updated to reflect that it's offline.) To complete the patch it would be necessary to set each leaf vdev's status from the newest vdev_label rather than from the first vdev_label seen. I think I've also hit a stack overflow a couple of times while debugging. I don't know enough about the gptzfsboot/loader.zfs environment to know whether the heap size could be easily enlarged, or whether there is room for a real malloc() with free(). loader(8) seems to use the malloc() in libstand. Can anyone shed some light on the memory limitations and possible solutions? I won't be able to spend much more time on this, but I wanted to pass on what I've learned in case someone else has the time and boot fu to take it the next step. Matt --00504502b672cac4d00478d6ed9a Content-Type: application/octet-stream; name="zfsboot-status.patch" Content-Disposition: attachment; filename="zfsboot-status.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g29nt7rn0 LS0tIHpmcy96ZnNpbXBsLmMub3JpZwkyMDA5LTEwLTI0IDE4OjEwOjI5LjAwMDAwMDAwMCAtMDcw MAorKysgemZzL3pmc2ltcGwuYwkyMDA5LTExLTIwIDE2OjQ0OjQ5LjAwMDAwMDAwMCAtMDgwMApA QCAtMzk2LDYgKzM5Niw3IEBACiAJdmRldi0+dl9yZWFkID0gcmVhZDsKIAl2ZGV2LT52X3BoeXNf cmVhZCA9IDA7CiAJdmRldi0+dl9yZWFkX3ByaXYgPSAwOworCXZkZXYtPnZfaW5pdGVkID0gMDsK IAlTVEFJTFFfSU5TRVJUX1RBSUwoJnpmc192ZGV2cywgdmRldiwgdl9hbGxsaW5rKTsKIAogCXJl dHVybiAodmRldik7CkBAIC00MTEsNiArNDEyLDcgQEAKIAl2ZGV2X3QgKnZkZXYsICpraWQ7CiAJ Y29uc3QgdW5zaWduZWQgY2hhciAqa2lkczsKIAlpbnQgbmtpZHMsIGk7CisJdWludDY0X3QgaXNf b2ZmbGluZSwgaXNfZmF1bHRlZCwgaXNfZGVncmFkZWQsIGlzX3JlbW92ZWQ7CiAKIAlpZiAobnZs aXN0X2ZpbmQobnZsaXN0LCBaUE9PTF9DT05GSUdfR1VJRCwKIAkJCURBVEFfVFlQRV9VSU5UNjQs IDAsICZndWlkKQpAQCAtNDc4LDYgKzQ4MCwyNiBAQAogCQkJdmRldi0+dl9uYW1lID0gc3RyZHVw KHR5cGUpOwogCQl9CiAJfQorCisJaWYgKCFudmxpc3RfZmluZChudmxpc3QsIFpQT09MX0NPTkZJ R19PRkZMSU5FLAorCQkJIERBVEFfVFlQRV9VSU5UNjQsIDAsICZpc19vZmZsaW5lKSAmJgorCQkJ IGlzX29mZmxpbmUpIHsKKwkJdmRldi0+dl9zdGF0ZSA9IFZERVZfU1RBVEVfT0ZGTElORTsKKwl9 IGVsc2UgaWYgKCFudmxpc3RfZmluZChudmxpc3QsIFpQT09MX0NPTkZJR19SRU1PVkVELAorCQkJ CURBVEFfVFlQRV9VSU5UNjQsIDAsICZpc19yZW1vdmVkKSAmJgorCQkJCWlzX3JlbW92ZWQpIHsK KwkJdmRldi0+dl9zdGF0ZSA9IFZERVZfU1RBVEVfUkVNT1ZFRDsKKwl9IGVsc2UgaWYgKCFudmxp c3RfZmluZChudmxpc3QsIFpQT09MX0NPTkZJR19GQVVMVEVELAorCQkJCURBVEFfVFlQRV9VSU5U NjQsIDAsICZpc19mYXVsdGVkKSAmJgorCQkJCWlzX2ZhdWx0ZWQpIHsKKwkJdmRldi0+dl9zdGF0 ZSA9IFZERVZfU1RBVEVfRkFVTFRFRDsKKwl9IGVsc2UgaWYgKCFudmxpc3RfZmluZChudmxpc3Qs IFpQT09MX0NPTkZJR19ERUdSQURFRCwKKwkJCQlEQVRBX1RZUEVfVUlOVDY0LCAwLCAmaXNfZGVn cmFkZWQpICYmCisJCQkJaXNfZGVncmFkZWQpIHsKKwkJdmRldi0+dl9zdGF0ZSA9IFZERVZfU1RB VEVfREVHUkFERUQ7CisJfSBlbHNlCisJCXZkZXYtPnZfc3RhdGUgPSBWREVWX1NUQVRFX0hFQUxU SFk7CisKIAlyYyA9IG52bGlzdF9maW5kKG52bGlzdCwgWlBPT0xfQ09ORklHX0NISUxEUkVOLAog CQkJIERBVEFfVFlQRV9OVkxJU1RfQVJSQVksICZua2lkcywgJmtpZHMpOwogCS8qCkBAIC01OTEs NyArNjEzLDkgQEAKIAkJIlVOS05PV04iLAogCQkiQ0xPU0VEIiwKIAkJIk9GRkxJTkUiLAorCQki UkVNT1ZFRCIsCiAJCSJDQU5UX09QRU4iLAorCQkiRkFVTFRFRCIsCiAJCSJERUdSQURFRCIsCiAJ CSJPTkxJTkUiCiAJfTsKQEAgLTgwNiw3ICs4MzAsNyBAQAogCQlyZXR1cm4gKEVJTyk7CiAJfQog CXZkZXYgPSB2ZGV2X2ZpbmQoZ3VpZCk7Ci0JaWYgKHZkZXYgJiYgdmRldi0+dl9zdGF0ZSA9PSBW REVWX1NUQVRFX0hFQUxUSFkpIHsKKwlpZiAodmRldiAmJiB2ZGV2LT52X2luaXRlZCkgewogCQly ZXR1cm4gKEVJTyk7CiAJfQogCkBAIC04MzYsNyArODYwLDcgQEAKIAlpZiAodmRldikgewogCQl2 ZGV2LT52X3BoeXNfcmVhZCA9IHJlYWQ7CiAJCXZkZXYtPnZfcmVhZF9wcml2ID0gcmVhZF9wcml2 OwotCQl2ZGV2LT52X3N0YXRlID0gVkRFVl9TVEFURV9IRUFMVEhZOworCQl2ZGV2LT52X2luaXRl ZCA9IDE7CiAJfSBlbHNlIHsKIAkJcHJpbnRmKCJaRlM6IGluY29uc2lzdGVudCBudmxpc3QgY29u dGVudHNcbiIpOwogCQlyZXR1cm4gKEVJTyk7Ci0tLSB6ZnNpbXBsLmgub3JpZwkyMDA5LTA1LTE2 IDAzOjQ4OjIwLjAwMDAwMDAwMCAtMDcwMAorKysgemZzaW1wbC5oCTIwMDktMTEtMTMgMTc6MzI6 MDYuMDAwMDAwMDAwIC0wODAwCkBAIC01MjgsNyArNTI4LDYgQEAKICNkZWZpbmUJWlBPT0xfQ09O RklHX0RUTAkJIkRUTCIKICNkZWZpbmUJWlBPT0xfQ09ORklHX1NUQVRTCQkic3RhdHMiCiAjZGVm aW5lCVpQT09MX0NPTkZJR19XSE9MRV9ESVNLCQkid2hvbGVfZGlzayIKLSNkZWZpbmUJWlBPT0xf Q09ORklHX09GRkxJTkUJCSJvZmZsaW5lIgogI2RlZmluZQlaUE9PTF9DT05GSUdfRVJSQ09VTlQJ CSJlcnJvcl9jb3VudCIKICNkZWZpbmUJWlBPT0xfQ09ORklHX05PVF9QUkVTRU5UCSJub3RfcHJl c2VudCIKICNkZWZpbmUJWlBPT0xfQ09ORklHX1NQQVJFUwkJInNwYXJlcyIKQEAgLTUzOCw2ICs1 MzcsMTYgQEAKICNkZWZpbmUJWlBPT0xfQ09ORklHX0hPU1ROQU1FCQkiaG9zdG5hbWUiCiAjZGVm aW5lCVpQT09MX0NPTkZJR19USU1FU1RBTVAJCSJ0aW1lc3RhbXAiIC8qIG5vdCBzdG9yZWQgb24g ZGlzayAqLwogCisvKgorICogVGhlIHBlcnNpc3RlbnQgdmRldiBzdGF0ZSBpcyBzdG9yZWQgYXMg c2VwYXJhdGUgdmFsdWVzIHJhdGhlciB0aGFuIGEgc2luZ2xlCisgKiAndmRldl9zdGF0ZScgZW50 cnkuICBUaGlzIGlzIGJlY2F1c2UgYSBkZXZpY2UgY2FuIGJlIGluIG11bHRpcGxlIHN0YXRlcywg c3VjaAorICogYXMgb2ZmbGluZSBhbmQgZGVncmFkZWQuCisgKi8KKyNkZWZpbmUgWlBPT0xfQ09O RklHX09GRkxJTkUgICAgICAgICAgICAib2ZmbGluZSIKKyNkZWZpbmUgWlBPT0xfQ09ORklHX0ZB VUxURUQgICAgICAgICAgICAiZmF1bHRlZCIKKyNkZWZpbmUgWlBPT0xfQ09ORklHX0RFR1JBREVE ICAgICAgICAgICAiZGVncmFkZWQiCisjZGVmaW5lIFpQT09MX0NPTkZJR19SRU1PVkVEICAgICAg ICAgICAgInJlbW92ZWQiCisKICNkZWZpbmUJVkRFVl9UWVBFX1JPT1QJCQkicm9vdCIKICNkZWZp bmUJVkRFVl9UWVBFX01JUlJPUgkJIm1pcnJvciIKICNkZWZpbmUJVkRFVl9UWVBFX1JFUExBQ0lO RwkJInJlcGxhY2luZyIKQEAgLTU3MCw3ICs1NzksOSBAQAogCVZERVZfU1RBVEVfVU5LTk9XTiA9 IDAsCS8qIFVuaW5pdGlhbGl6ZWQgdmRldgkJCSovCiAJVkRFVl9TVEFURV9DTE9TRUQsCS8qIE5v dCBjdXJyZW50bHkgb3BlbgkJCSovCiAJVkRFVl9TVEFURV9PRkZMSU5FLAkvKiBOb3QgYWxsb3dl ZCB0byBvcGVuCQkJKi8KKyAgICAgICAgVkRFVl9TVEFURV9SRU1PVkVELAkvKiBFeHBsaWNpdGx5 IHJlbW92ZWQgZnJvbSBzeXN0ZW0JKi8KIAlWREVWX1NUQVRFX0NBTlRfT1BFTiwJLyogVHJpZWQg dG8gb3BlbiwgYnV0IGZhaWxlZAkJKi8KKyAgICAgICAgVkRFVl9TVEFURV9GQVVMVEVELAkvKiBF eHRlcm5hbCByZXF1ZXN0IHRvIGZhdWx0IGRldmljZQkqLwogCVZERVZfU1RBVEVfREVHUkFERUQs CS8qIFJlcGxpY2F0ZWQgdmRldiB3aXRoIHVuaGVhbHRoeSBraWRzCSovCiAJVkRFVl9TVEFURV9I RUFMVEhZCS8qIFByZXN1bWVkIGdvb2QJCQkqLwogfSB2ZGV2X3N0YXRlX3Q7CkBAIC0xMTU4LDYg KzExNjksNyBAQAogCXZkZXZfcGh5c19yZWFkX3QgKnZfcGh5c19yZWFkOwkvKiByZWFkIGZyb20g cmF3IGxlYWYgdmRldiAqLwogCXZkZXZfcmVhZF90CSp2X3JlYWQ7CS8qIHJlYWQgZnJvbSB2ZGV2 ICovCiAJdm9pZAkJKnZfcmVhZF9wcml2OwkvKiBwcml2YXRlIGRhdGEgZm9yIHJlYWQgZnVuY3Rp b24gKi8KKwlpbnQJCXZfaW5pdGVkOwogfSB2ZGV2X3Q7CiAKIC8qCg== --00504502b672cac4d00478d6ed9a--