From owner-freebsd-stable@FreeBSD.ORG Wed May 25 09:36:22 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F02C81065677; Wed, 25 May 2011 09:36:22 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id 23AA78FC13; Wed, 25 May 2011 09:36:21 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 6DEE827; Wed, 25 May 2011 11:36:20 +0200 (MET DST) Date: Wed, 25 May 2011 11:36:20 +0200 From: Joerg Wunsch To: freebsd-stable@FreeBSD.org Message-ID: <20110525093620.GA1917@uriah.heep.sax.de> References: <20110524055408.GA2110@uriah.heep.sax.de> <4DDB54A3.2050205@FreeBSD.org> <20110524072618.GB2110@uriah.heep.sax.de> <20110524085302.GA9939@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110524085302.GA9939@icarus.home.lan> X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: lulf@freebsd.org, Andriy Gapon , Jeremy Chadwick , phk@freebsd.org Subject: Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:36:23 -0000 As Jeremy Chadwick wrote: > Just an informational note about inducing a panic: I tend to, once at > the db> prompt, do "bt" then immediately "call doadump". That induces > memory being written to swap, then do "reboot". OK, reproduced the panic (which was easy ;), and did it that way. Now, the stack trace makes sense: (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc0475049 in db_fncall (dummy1=249790, dummy2=0, dummy3=0, dummy4=0xc69b8914 "\220#\003") at /usr/src/sys/ddb/db_command.c:548 #2 0xc0475441 in db_command (last_cmdp=0xc08780fc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc047559a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04774bd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc05a9422 in kdb_trap (type=3, code=0, tf=0xc69b8ac0) at /usr/src/sys/kern/subr_kdb.c:548 #6 0xc079a25e in trap (frame=0xc69b8ac0) at /usr/src/sys/i386/i386/trap.c:721 #7 0xc077fcbc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #8 0xc05a92aa in kdb_enter (why=0xc07f7e81 "panic", msg=0xc07f7e81 "panic") at cpufunc.h:71 #9 0xc05796f4 in panic (fmt=0xc07eeafc "wrong offset %jd for sectorsize %u") at /usr/src/sys/kern/kern_shutdown.c:575 #10 0xc051d28c in g_io_request (bp=0xc82f4d20, cp=0xc8cf0780) at /usr/src/sys/geom/geom_io.c:427 #11 0xc051daa1 in g_read_data (cp=0xc8cf0780, offset=4096, length=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/geom/geom_io.c:704 #12 0xc09c5692 in gv_read_header (cp=0xc8cf0780, m_hdr=0xc69b8c08) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum_drive.c:129 #13 0xc09c0e1b in gv_taste (mp=0xc09d75a0, pp=0xcbab9600, flags=0) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum.c:613 #14 0xc05209df in g_new_provider_event (arg=0xcbab9600, flag=0) at /usr/src/sys/geom/geom_subr.c:551 #15 0xc051cb44 in g_run_events () at /usr/src/sys/geom/geom_event.c:212 #16 0xc051e52a in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:140 #17 0xc054f948 in fork_exit (callout=0xc051e4a0 , arg=0x0, frame=0xc69b8d28) at /usr/src/sys/kern/kern_fork.c:865 #18 0xc077fd34 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) up 10 #10 0xc051d28c in g_io_request (bp=0xc82f4d20, cp=0xc8cf0780) at /usr/src/sys/geom/geom_io.c:427 427 KASSERT(bp->bio_offset % cp->provider->sectorsize == 0, (kgdb) up #11 0xc051daa1 in g_read_data (cp=0xc8cf0780, offset=4096, length=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/geom/geom_io.c:704 704 g_io_request(bp, cp); (kgdb) up #12 0xc09c5692 in gv_read_header (cp=0xc8cf0780, m_hdr=0xc69b8c08) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum_drive.c:129 129 d_hdr = g_read_data(cp, GV_HDR_OFFSET, pp->sectorsize, NULL); (kgdb) l 124 KASSERT(m_hdr != NULL, ("gv_read_header: null m_hdr")); 125 KASSERT(cp != NULL, ("gv_read_header: null cp")); 126 pp = cp->provider; 127 KASSERT(pp != NULL, ("gv_read_header: null pp")); 128 129 d_hdr = g_read_data(cp, GV_HDR_OFFSET, pp->sectorsize, NULL); 130 if (d_hdr == NULL) 131 return (-1); 132 off = 0; 133 m_hdr->magic = GV_GET64(be); (kgdb) p cp->provider->sectorsize $1 = 2352 (kgdb) up #13 0xc09c0e1b in gv_taste (mp=0xc09d75a0, pp=0xcbab9600, flags=0) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum.c:613 613 error = gv_read_header(cp, &vhdr); So the panic happens because gvinum is being asked to "taste" the audio CD device when it's being opened, and gvinum in turn tries to read the header (at offset 4096) from it. Well, the workaround is easy (just return -1 from gv_taste() when noticing the offset is not on a sector boundary - this can never be a valid gvinum device anyway), but I'm curious about why this panic now happens in RELENG_8 when it didn't before. I see Ulf Lilleengen changed a lot there in the gvinum code (thus cc'ing him), maybe he's got an explanation. Previously, gvinum used to have three different "taste" methods for drives, plexes, and volumes, respectively, while now everything appears to be unified in a single gv_taste() method. Somehow, therein must lie the actual problem. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)