From owner-cvs-src@FreeBSD.ORG Tue Oct 17 10:53:38 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF5BF16A407; Tue, 17 Oct 2006 10:53:38 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id C725B43D5D; Tue, 17 Oct 2006 10:53:34 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k9HArUYU021591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 14:53:30 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k9HArUSW021590; Tue, 17 Oct 2006 14:53:30 +0400 (MSD) (envelope-from oleg) Date: Tue, 17 Oct 2006 14:53:30 +0400 From: Oleg Bulyzhin To: John-Mark Gurney Message-ID: <20061017105330.GC20789@lath.rinet.ru> References: <200610091615.k99GFuPD054744@repoman.freebsd.org> <20061016081442.GA344@lath.rinet.ru> <20061016170517.GF23971@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061016170517.GF23971@funkthat.com> User-Agent: Mutt/1.5.11 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/pci pci.c pci_if.m pci_private.h pcivar.h src/sys/dev/sk if_sk.c if_skreg.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 10:53:38 -0000 On Mon, Oct 16, 2006 at 10:05:17AM -0700, John-Mark Gurney wrote: > Oleg Bulyzhin wrote this message on Mon, Oct 16, 2006 at 12:14 +0400: > > On Mon, Oct 09, 2006 at 04:15:56PM +0000, John-Mark Gurney wrote: > > > jmg 2006-10-09 16:15:56 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/dev/pci pci.c pci_if.m pci_private.h pcivar.h > > > sys/dev/sk if_sk.c if_skreg.h > > > Log: > > > provide routines to access VPD data at the PCI layer... > > > > > > remove sk's own implementation, and use the new calls to get the data... > > > > > > Reviewed by: -arch > > > > > > Revision Changes Path > > > 1.315 +339 -3 src/sys/dev/pci/pci.c > > > 1.9 +13 -0 src/sys/dev/pci/pci_if.m > > > 1.18 +4 -0 src/sys/dev/pci/pci_private.h > > > 1.71 +34 -0 src/sys/dev/pci/pcivar.h > > > 1.131 +7 -148 src/sys/dev/sk/if_sk.c > > > 1.39 +0 -31 src/sys/dev/sk/if_skreg.h > > > > I have problem with my test machine since this commit: > > kernel is panicing on boot if i have my pci bge(4) NIC plugged in. > > > > Last kernel messages are: > > pci1: physical bus=1 > > pci1:2:0: bad VPD cksum, remain 244 > > > > Invoking ddb after panic gives this backtrace: > > [skipped] > > pci_read_vpd > > pci_read_extcap > > pci_read_device > > pci_add_children > > acpi_pci_attach > > device_attach > > [skipped] > > > > (i'm unable to get crashdump) > > > > If i unplug bge, kernel boots just fine. > > > > P.S. i can provide any additional info needed and can test patches. > > Can you get a line number from pci_read_vpd? Even if you can't get a > crash dump, you can use addr2line (or kgdb) w/ the ip of the panic... > That would help.. > > Looks like some manufacturers aren't following the PCI standard.. :( > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." Okay, there is some details: When kernel boots with bge plugged in: 1) message about bad VPD cksum 2) then kernel seems to hang for about 30 seconds (i'm not able to break into DDB) 3) then i get panic. Panic message is about trap inside 'swapper' process (backtrace shows 2 traps first inside pci_read_vpd, next one in swapper). 1st trap is at pci_read_vpd+0x2c6 it is /usr/src/sys/dev/pci/pci.c:665 I've added debug printf there: case 3: /* VPD-R Keyword Value */ printf("off: %d i: %d\n", off, i); cfg->vpd.vpd_ros[off].value[i++] = byte; It seems that 30 seconds delay is memory rewriting (off is constant, while i is incrementing). I get panic message after: off:5 i:15407 -- Oleg.