RELENG_8: panic: wrong offset 4096 for sectorsize 2352

[Joerg Wunsch]

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 <g_event_procbody>, 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. ;-)