From ats@freebsd.first.gmd.de  Sat May 31 12:17:01 1997
Received: from freebsd.first.gmd.de (freebsd.first.gmd.de [194.95.170.200])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05876
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 31 May 1997 12:16:58 -0700 (PDT)
Received: (from ats@localhost) by freebsd.first.gmd.de (8.8.5/8.6.12) id VAA04562; Sat, 31 May 1997 21:23:57 +0200 (MET DST)
Message-Id: <199705311923.VAA04562@freebsd.first.gmd.de>
Date: Sat, 31 May 1997 21:23:57 +0200 (MET DST)
From: Andreas Schulz <ats@freebsd.first.gmd.de>
Reply-To: ats@freebsd.first.gmd.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: kern pci detection
X-Send-Pr-Version: 3.2

>Number:         3731
>Category:       kern
>Synopsis:       Addition of a PCI Bridge
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat May 31 12:20:01 PDT 1997
>Closed-Date:    Fri Jul 3 02:06:03 PDT 1998
>Last-Modified:  Fri Jul  3 02:06:19 PDT 1998
>Originator:     Andreas Schulz
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
GMD-FIRST
>Environment:

FreeBSD-3.0 current.

>Description:

The ALI Acer Labs Inc. Host to PCI bridge is missing/detected as an
unknown controller from the PCI Code.
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.

May 30 16:38:22 pctest /kernel: pcibus_setup(1):	mode 1 addr port (0x0cf8) is 0x00000000
May 30 16:38:22 pctest /kernel: pcibus_setup(1a):	mode1res=0x00000000 (0x80000000)
May 30 16:38:23 pctest /kernel: pcibus_setup(1b):	mode1res=0x80000000 (0xff000001)
May 30 16:38:23 pctest /kernel: pcibus_check:	device 0 [class=60000] [hdr=0] is there (id=148910b9)
May 30 16:38:23 pctest /kernel: Probing for devices on PCI bus 0:
May 30 16:38:23 pctest /kernel: 	configuration mode 1 allows 32 devices.
May 30 16:38:23 pctest /kernel: chip0 <Host to PCI bridge (vendor=10b9 device=1489)> rev 0 on pci0:0:0

>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:

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
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Fri Jul 3 02:06:03 PDT 1998 
State-Changed-Why:  
As part of our PR audition campaign, this PR has been closed.  The subject 
does not seem likely to ever gain any attention, and consequently I have 
chosen to close the PR, rather than have it clutter up the PR database. 

We apologize for late response to this PR. 

>Unformatted:
