Date: Tue, 24 May 2011 01:53:02 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-stable@FreeBSD.org, phk@freebsd.org, Andriy Gapon <avg@FreeBSD.org> Subject: Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352 Message-ID: <20110524085302.GA9939@icarus.home.lan> In-Reply-To: <20110524072618.GB2110@uriah.heep.sax.de> References: <20110524055408.GA2110@uriah.heep.sax.de> <4DDB54A3.2050205@FreeBSD.org> <20110524072618.GB2110@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 24, 2011 at 09:26:18AM +0200, Joerg Wunsch wrote:
> As Andriy Gapon wrote:
>
> > > panic: wrong offset 4096 for sectorsize 2352
> > >
> > > Any ideas why this happens, and how to avoid it?
>
> > Backtrace would be a first thing.
>
> OK, here we go (the core has been dumped from within a serial console
> BREAK DDB entry, I'm omitting the frames related to that):
>
> #16 0xc0537352 in _cv_wait (cvp=0xc6e6bcd4, lock=0xc6e6bdd4) at /usr/src/sys/kern/kern_condvar.c:96
> #17 0xc0aa8a13 in usb_process (arg=0xc6e6bccc)
> at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_process.c:183
> #18 0xc054f948 in fork_exit (callout=0xc0aa88e0 <usb_process>, arg=0xc6e6bccc, frame=0xc6a1ad28)
> at /usr/src/sys/kern/kern_fork.c:865
> #19 0xc077fd34 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275
>
> After the initial panic, I typed "c" in DDB, in the assumption
> it would proceed with a coredump, but it didn't. That's why I
> hit BREAK again, and forced a dump through the "panic" DDB
> command. Now, I'm no longer sure whether the frames above do
> really relate to the mentioned panic string.
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". I assume (since you
have a crash at all) that you have dumpdev defined in /etc/rc.conf.
savecore(8) will then pick up the panic, etc... you get the idea.
The panic in question is intentional from what I can tell in the code.
I'm not sure how much a kernel crash/dump is going to help with this,
given the following code in src/sys/geom/geom_io.c:
391 void
392 g_io_request(struct bio *bp, struct g_consumer *cp)
393 {
...
426 if (bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_DELETE)) {
427 KASSERT(bp->bio_offset % cp->provider->sectorsize == 0,
428 ("wrong offset %jd for sectorsize %u",
429 bp->bio_offset, cp->provider->sectorsize));
phk@ added this code 6 years ago to HEAD (at the time); see the
annotation around line 426:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/geom_io.c#rev1.59
The assertion failed because sectorsize was not a multiple of
bio_offset. Specifically: 4096 / 2352 = 1.741, which isn't zero,
therefore the panic occurs. (It's important to read assertions
"backwards"; that is, the assertion/panic happens when the conditional
proves false).
I know little to nothing about CD ripping so I can't tell you why abcde
was able to somehow trigger this. Possibly some device read routines
that abcde uses get translated directly into GEOM requests and therefore
indirectly trigger the assertion?
I'm CC'ing phk@ in case he happens to know what may be going on here, or
has seen this in the wild as well, but I imagine his plate is quite full
right now.
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110524085302.GA9939>