From owner-freebsd-current Mon May 26 12:48:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA07516 for current-outgoing; Mon, 26 May 1997 12:48:35 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA07510 for ; Mon, 26 May 1997 12:48:32 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-1.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA08877 (5.67b/IDA-1.5 for ); Mon, 26 May 1997 21:48:29 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id VAA04268; Mon, 26 May 1997 21:48:28 +0200 (CEST) X-Face: " Date: Mon, 26 May 1997 21:48:27 +0200 From: Stefan Esser To: Steve Passe Cc: current@FreeBSD.ORG Subject: Re: recent PCI code changes broken? References: <199705261915.NAA04530@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199705261915.NAA04530@Ilsa.StevesCafe.com>; from Steve Passe on Mon, May 26, 1997 at 01:15:39PM -0600 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 26, Steve Passe wrote: > Hi, > > I am having trouble with the most recent sys code not finding PCI devices. > I discovered this after resupping my just committed changes to exception.s, > vector.s and icu.s. However I (locally) restored the old versions of these > and the problem still exists. Specifically none of the PCI devices appear > to be discovered during the probe, in either the UP or SMP models. Ohh, sorry, this may really be caused by my changes ... :( I tested them for two days (extracted clean kernel trees, built various kernels (GENERIC and custom) and booted them, and prepared a large patch file to be sure that no part of this change (which affected 13 source files) was lost ... Anyway, if I messed up, I'm sorry and will try to fix all problems I might have introduced as fast as possible! > Could the problem be with the recently committed PCI code? Yes, I'm afraid ... > I'm looking into this now, please send any clues my way... Please let me look into this, too :) What does a VERBOSE boot print when testing for the PCI chip set ? On my (old) Saturn II based SP3G it looks like this: % CPU: AMD Am5x86 Write-Through (486-class CPU) % Origin = "AuthenticAMD" Id = 0x4e4 Stepping=4 % Features=0x1 % real memory = 33554432 (32768K bytes) % avail memory = 30900224 (30176K bytes) % pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 % pci_open(1a): mode1res=0x00000000 (0x80000000) % pci_open(1b): mode1res=0x00000000 (0xff000001) % pci_open(2): mode 2 enable port (0x0cf8) is 0x00 % pci_open(2a): mode2res=0x0e (0x0e) % pci_open(2a): now trying mechanism 2 % pci_cfgcheck: device 0 [class=000000] 1 [class=000000] 2 [class=000000] 3 4 [class=010000] [hdr=00] is there (id=000f1000) % Probing for devices on PCI bus 0: Please write down all the numbers from the labels (1,1a,...) and the values reported, iff there is NO success reported in the pci_cfgcheck line, or if that line is completely missing. (If you warm boot /kernel.old, the message buffer might be saved completely, and these lines that appear right at the top will be included. I used this a lot during debugging of that code :) If the PCI chip set is found (i.e. pci_cfgcheck succeeds), then I need to know what the device probe returns. For that to be reported as part of a verbose boot, you need to build a kernel with "options PCI_DEBUG" defined ... Sorry for the inconvenience. I'm willing to spend the next few hours to get this resolved ! Regards, STefan