From owner-freebsd-geom@FreeBSD.ORG Thu Oct 14 13:41:25 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE4D916A4CE; Thu, 14 Oct 2004 13:41:25 +0000 (GMT) Received: from mrynet.com (mrynet.com [63.231.249.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43A5143D4C; Thu, 14 Oct 2004 13:41:25 +0000 (GMT) (envelope-from staylor@mrynet.com) Received: from mrynet.com (staylor@localhost [127.0.0.1]) by mrynet.com (8.13.1/8.13.1) with ESMTP id i9EDfOal006487; Thu, 14 Oct 2004 08:41:24 -0500 (CDT) (envelope-from staylor@mrynet.com) Received: (from staylor@localhost) by mrynet.com (8.13.1/8.13.1/Submit) id i9EDfOhU006486; Thu, 14 Oct 2004 08:41:24 -0500 (CDT) (envelope-from staylor) Message-Id: <200410141341.i9EDfOhU006486@mrynet.com> From: staylor@mrynet.com (User Staylor) Date: Thu, 14 Oct 2004 08:41:24 -0500 X-Mailer: Mail User's Shell (7.2.6 beta(5) jp(8) 11/23/00) To: "Poul-Henning Kamp" cc: freebsd-current@freebsd.org cc: freebsd-geom@freebsd.org Subject: Re: GEOM will panic 6.0-current on userland wrong-length disk reads X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 13:41:26 -0000 > Do you have rev. 1.63 of sys/geom/geom_io.c ? Yes: ttyp6:--ROOT--@mrynet (74): ident kernel | grep geom_io $FreeBSD: /repoman/r/ncvs/src/sys/geom/geom_io.c,v 1.63 2004/10/11 21:22:59 ups Exp $ And I've found that simply commenting-out the following resolves the issue: ttyp6:--ROOT--@mrynet (58): diff -C 10 geom_io.c- geom_io.c *** geom_io.c- Thu Oct 14 08:30:44 2004 --- geom_io.c Thu Oct 14 08:31:12 2004 *************** *** 238,265 **** --- 238,267 ---- g_io_request(struct bio *bp, struct g_consumer *cp) { struct g_provider *pp; KASSERT(cp != NULL, ("NULL cp in g_io_request")); KASSERT(bp != NULL, ("NULL bp in g_io_request")); KASSERT(bp->bio_data != NULL, ("NULL bp->data in g_io_request")); pp = cp->provider; KASSERT(pp != NULL, ("consumer not attached in g_io_request")); + #ifdef notyet if (bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_DELETE)) { KASSERT(bp->bio_offset % cp->provider->sectorsize == 0, ("wrong offset %jd for sectorsize %u", bp->bio_offset, cp->provider->sectorsize)); KASSERT(bp->bio_length % cp->provider->sectorsize == 0, ("wrong length %jd for sectorsize %u", bp->bio_length, cp->provider->sectorsize)); } + #endif g_trace(G_T_BIO, "bio_request(%p) from %p(%s) to %p(%s) cmd %d", bp, cp, cp->geom->name, pp, pp->name, bp->bio_cmd); bp->bio_from = cp; bp->bio_to = pp; bp->bio_error = 0; bp->bio_completed = 0; KASSERT(!(bp->bio_flags & BIO_ONQUEUE), If you're indicating that you are unable to duplicate this panic, let me know. I'll resort to pitching my current /usr/src tree and re-cvsup and retry. -scott > > In message <200410140521.i9E5L06d001096@mrynet.com>, User Staylor writes: > >Just discovered (and verified with latest build on > >current.freebsd.org) that the following will panic > >the new GEOM fdc driver in 6.0-current: > > > ># dd if=/dev/fd0 bs=55 > >panic: wrong length 55 for sectorsize 512 > > > >And further checking, discovered that ALL disk devices will cause > >a panic: > > > >dd if=/dev/ad0 bs=1234 > >panic: wrong length 1234 for sectorsize 512 > > > >Perhaps this is geom's way of complaining? Seems a rather radical > >way to handle non-matching-blocksize reads of disk devices. A > >simple programming error reading a disk dev node will panic the > >machine. > > > >-scott > >_______________________________________________ > >freebsd-geom@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-geom > >To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence.