From owner-freebsd-current@FreeBSD.ORG Mon Apr 1 16:22:36 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0282AD3D for ; Mon, 1 Apr 2013 16:22:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4C234F8 for ; Mon, 1 Apr 2013 16:22:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA26193; Mon, 01 Apr 2013 19:22:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5159B448.2080500@FreeBSD.org> Date: Mon, 01 Apr 2013 19:22:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fabian Keil Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4d5ea364 == 0x2f505a), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 625 References: <20130401161813.6e42e2a1@fabiankeil.de> <5159A517.5070802@FreeBSD.org> <20130401175126.1d28b0f4@fabiankeil.de> In-Reply-To: <20130401175126.1d28b0f4@fabiankeil.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:22:36 -0000 on 01/04/2013 18:51 Fabian Keil said the following: > vmcore.13: > > (kgdb) p *dn->dn_phys > Cannot access memory at address 0xffffff8015eeb800 > (kgdb) p *dn->dn_dbuf > $1 = {db = {db_object = 0, db_offset = 28491776, db_size = 16384, db_data = 0xffffff8015eeb000}, db_objset = 0xfffffe00691a5000, db_dnode_handle = 0xfffffe00691a5020, db_parent = 0xfffffe004254ab60, > db_hash_next = 0x0, db_blkid = 1739, db_blkptr = 0xffffff8015d65580, db_level = 0 '\0', db_mtx = {lock_object = {lo_name = 0xffffffff811d8696 "db->db_mtx", lo_flags = 40960000, lo_data = 0, > lo_witness = 0x0}, sx_lock = 1}, db_state = DB_CACHED, db_holds = {rc_count = 2}, db_buf = 0xfffffe0042bedcf0, db_changed = {cv_description = 0xffffffff811d86a2 "db->db_changed", cv_waiters = 0}, > db_data_pending = 0xfffffe00406d6500, db_last_dirty = 0xfffffe00406d6500, db_link = {list_next = 0xfffffe0042758c10, list_prev = 0xfffffe0069cab5f8}, db_user_ptr = 0xfffffe0069f70000, > db_user_data_ptr_ptr = 0x0, db_evict_func = 0xffffffff81105770 , db_immediate_evict = 0 '\0', db_freed_in_flight = 0 '\0', db_dirtycnt = 1 '\001'} That's interesting. So db.db_data has a bogus address. Not sure how that could happen and what to make of it yet. -- Andriy Gapon