From owner-freebsd-current@FreeBSD.ORG Sun Sep 11 03:31:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC29F16A41F; Sun, 11 Sep 2005 03:31:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D45943D45; Sun, 11 Sep 2005 03:31:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8B3Ttcs064012; Sat, 10 Sep 2005 21:29:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 10 Sep 2005 21:29:38 -0600 (MDT) Message-Id: <20050910.212938.106824122.imp@bsdimp.com> To: joao.barros@gmail.com From: "M. Warner Losh" In-Reply-To: <70e8236f05091016251510408c@mail.gmail.com> References: <70e8236f05090513381584dda0@mail.gmail.com> <70e8236f0509051350e020f76@mail.gmail.com> <70e8236f05091016251510408c@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 10 Sep 2005 21:29:56 -0600 (MDT) Cc: freebsd-current@freebsd.org, mike@sentex.net Subject: Re: 6.0-CURRENT SNAP004 hangs on amr (patch) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2005 03:31:55 -0000 In message: <70e8236f05091016251510408c@mail.gmail.com> Joao Barros writes: : Looking at pciconf -l -v : : pcib3@pci2:0:0: class=0x060400 card=0x000000dc chip=0xb1548086 rev=0x00 hdr=0x01 : vendor = 'Intel Corporation' : device = 'S21152BA,S21154AE/BE PCI to PCI Bridge' : class = bridge : subclass = PCI-PCI : none1@pci2:1:0: class=0x010000 card=0x8493101e chip=0x12161077 rev=0x06 hdr=0x00 : vendor = 'QLogic Corporation' : device = 'ISP12160 Dual Channel Ultra3 SCSI Processor' : class = mass storage : subclass = SCSI : amr0@pci3:0:0: class=0x010400 card=0x04931028 chip=0x1960101e rev=0x20 hdr=0x00 : vendor = 'American Megatrends Inc.' : device = '80960RP i960RP Microprocessor' : class = mass storage : subclass = RAID : : So, by not attaching a driver to pci2:1:0, the pci2:0:0 is disabled. : Although the 'real' amr is assigned to pci3, the pci bridge on : pci2:0:0 gets disabled thus killing the amr. One workaround less intrusive workaround would also be to add mass storage devices to the list of devices that we don't power down by default. That would catch all the cases that have been found to have issues, as far as I can recall. Since these aren't functions in the same slot, it can be very hard to know and recoginze this situation automatically. How do you tell it apart from two devices on the same bus? You can't easily tell this. I have a few ideas here, and will look into them. Warner