From owner-freebsd-bugs  Mon Jun  2 10:10:03 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id KAA29396
          for bugs-outgoing; Mon, 2 Jun 1997 10:10:03 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id KAA29373;
          Mon, 2 Jun 1997 10:10:00 -0700 (PDT)
Date: Mon, 2 Jun 1997 10:10:00 -0700 (PDT)
Message-Id: <199706021710.KAA29373@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Stefan Esser <se@FreeBSD.ORG>
Subject: Re: kern/3731: kern pci detection
Reply-To: Stefan Esser <se@FreeBSD.ORG>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/3731; it has been noted by GNATS.

From: Stefan Esser <se@FreeBSD.ORG>
To: ats@freebsd.first.gmd.de
Cc: FreeBSD-gnats-submit@freebsd.org, Stefan Esser <se@freebsd.org>
Subject: Re: kern/3731: kern pci detection
Date: Mon, 2 Jun 1997 15:40:36 +0200

 On May 31, Andreas Schulz <ats@freebsd.first.gmd.de> wrote:
 > The ALI Acer Labs Inc. Host to PCI bridge is missing/detected as an
 > unknown controller from the PCI Code.
 
 Well, yes, but where is the problem ? :)
 
 > vendor = 0x10b9  id=0x1489
 > This is a PCI-Chipset for 486 based Motherboard with the ALI
 > 1487/1489 Chips. A little bit of information can be found on the
 > the Web: www.ali.com.tw . It seems to work ok.
 
 Sure. The host to PCI bridge is among the very first
 devices to be initialized by the system BIOS. There 
 are a few (**very** few ...) such chips, that have to 
 be recognized and dealt with. The probe message does
 just document the system's chip set, in the hope that
 this information may prove useful in diagnosing some
 installation problem.
 
 > May 30 16:38:23 pctest /kernel: chip0 <Host to PCI bridge (vendor=10b9 device=1489)> rev 0 on pci0:0:0
 
 The PCI driver knows about the most common PCI chip 
 sets, and since each new entry adds some 100 bytes
 of kernel bloat for no real advantage, I do not want
 to add an ancient 486 chip set. But I will make sure,
 that the vendor ID of ALI is recognized and the name
 is printed instead of the numeric value.
 
 I'm going to close this PR, since there was nothing
 wrong. The numeric vendor and device ID uniquely
 identify the chip-set and no action has to be taken 
 by the kernel to deal with this chip-set.
 
 Gruss, STefan