From owner-freebsd-stable@FreeBSD.ORG Wed Jan 10 20:39:06 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D0C916A40F; Wed, 10 Jan 2007 20:39:06 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.freebsd.org (Postfix) with ESMTP id D9E8613C44C; Wed, 10 Jan 2007 20:39:05 +0000 (UTC) (envelope-from sven@dmv.com) Received: from mail-gw-cl-b.dmv.com (mail-gw-cl-b.dmv.com [216.240.97.39]) by smtp-gw-cl-c.dmv.com (8.12.10/8.12.10) with ESMTP id l0AKd10F053223; Wed, 10 Jan 2007 15:39:02 -0500 (EST) (envelope-from sven@dmv.com) Received: from [67.62.150.139] (static-67-62-150-139.dsl.cavtel.net [67.62.150.139]) (authenticated bits=0) by mail-gw-cl-b.dmv.com (8.12.9/8.12.9) with ESMTP id l0AKcv8s082002; Wed, 10 Jan 2007 15:39:00 -0500 (EST) (envelope-from sven@dmv.com) Message-ID: <45A54FC9.8040900@dmv.com> Date: Wed, 10 Jan 2007 15:42:49 -0500 From: Sven Willenberger User-Agent: Thunderbird 1.5.0.7 (X11/20060919) MIME-Version: 1.0 To: Bruce Evans References: <1168211205.22629.6.camel@lanshark.dmv.com> <20070109124826.M79616@delplex.bde.org> <1168353425.29047.8.camel@lanshark.dmv.com> <200701091150.15274.jhb@freebsd.org> <20070110132839.X16378@besplex.bde.org> In-Reply-To: <20070110132839.X16378@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.39 Cc: stable@freebsd.org, freebsd-amd64@freebsd.org, John Baldwin Subject: Re: Panic in 6.2-PRERELEASE with bge on amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 20:39:06 -0000 Bruce Evans presumably uttered the following on 01/09/07 21:42: > On Tue, 9 Jan 2007, John Baldwin wrote: > >> On Tuesday 09 January 2007 09:37, Sven Willenberger wrote: >>> On Tue, 2007-01-09 at 12:50 +1100, Bruce Evans wrote: >>>> Oops. I should have asked for the statment in bge_rxeof(). >>> >>> #7 0xffffffff801d5f17 in bge_rxeof (sc=0xffffffff8836b000) >> at /usr/src/sys/dev/bge/if_bge.c:2528 >>> 2528 m->m_pkthdr.len = m->m_len = cur_rx->bge_len - >> ETHER_CRC_LEN; >>> >>> (where m is defined as: >>> 2449 struct mbuf *m = NULL; >>> ) >> >> It's assigned earlier in between those two places. > > Its initialization here is just a style bug. > >> Can you 'p rxidx' as well >> as 'p sc->bge_cdata.bge_rx_std_chain[rxidx]' and 'p >> sc->bge_cdata.bge_rx_jumbo_chain[rxidx]'? Also, are you using jumbo >> frames >> at all? > > Also look at nearby chain entries (especially at (rxidx - 1) mod 512)). > I think the previous 255 entries and the rxidx one should be > non-NULL since we should have refilled them as we used them (so the > one at rxidx is least interesting since we certainly just refilled > it), and the next 256 entries should be NULL since we bogusly only use > half of the entries. If the problem is uninitialization, then I expect > all 512 entries except the one just refilled at rxidx to be NULL. > > Bruce > _______________________________________________ (kgdb) p sc->bge_cdata.bge_rx_std_chain[rxidx] $1 = (struct mbuf *) 0xffffff0097a27900 (kgdb) p rxidx $2 = 499 since rxidx = 499, I assume you are most interested in 498: (kgdb) p sc->bge_cdata.bge_rx_std_chain[498] $3 = (struct mbuf *) 0xffffff00cf1b3100 for the sake of argument, 500 is null: (kgdb) p sc->bge_cdata.bge_rx_std_chain[500] $13 = (struct mbuf *) 0x0 the indexes with values basically are 243 through 499: (kgdb) p sc->bge_cdata.bge_rx_std_chain[241] $30 = (struct mbuf *) 0x0 (kgdb) p sc->bge_cdata.bge_rx_std_chain[242] $31 = (struct mbuf *) 0x0 (kgdb) p sc->bge_cdata.bge_rx_std_chain[243] $32 = (struct mbuf *) 0xffffff005d4ab700 (kgdb) p sc->bge_cdata.bge_rx_std_chain[244] $33 = (struct mbuf *) 0xffffff004f644b00 so it does not seem to be a problem with "uninitialization".