From owner-freebsd-i386@FreeBSD.ORG Fri Jan 2 23:20:08 2004 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE94816A4CE for ; Fri, 2 Jan 2004 23:20:08 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD72E43D2D for ; Fri, 2 Jan 2004 23:20:07 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i037K7FR041798 for ; Fri, 2 Jan 2004 23:20:07 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i037K7ad041797; Fri, 2 Jan 2004 23:20:07 -0800 (PST) (envelope-from gnats) Date: Fri, 2 Jan 2004 23:20:07 -0800 (PST) Message-Id: <200401030720.i037K7ad041797@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Tai-hwa Liang Subject: Re: i386/57133: PCI device ID for Intel 82801DB/BAM/CAM and ATI Radeon Mobility 9000 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Tai-hwa Liang List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2004 07:20:08 -0000 The following reply was made to PR i386/57133; it has been noted by GNATS. From: Tai-hwa Liang To: John Baldwin Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: i386/57133: PCI device ID for Intel 82801DB/BAM/CAM and ATI Radeon Mobility 9000 Date: Sat, 3 Jan 2004 15:17:49 +0800 (CST) On Fri, 2 Jan 2004, John Baldwin wrote: > On 01-Jan-2004 Tai-hwa Liang wrote: > > On Wed, 31 Dec 2003, John Baldwin wrote: > >> Current no longer displays strings like these for unprobed devices. Instead, > >> a user can use 'pciconf -lv' to find out what all the unprobed devices on a > >> system are on both 4.x and 5.x. Having the descriptive strings in the > >> chip(4) driver is now obsolete. The pciconf method also has the advantage of > >> not making the kernel larger with all the strings. > > Does that mean this PR should be closed? > > Probably, but I was waiting to see what you thought first. Well, sounds that these strings did nothing with functional effect but only enlarge the kernel. I think this PR can be closed.