From nobody@FreeBSD.ORG Mon May 31 10:28:39 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 34AF914F62; Mon, 31 May 1999 10:28:39 -0700 (PDT)
Message-Id: <19990531172839.34AF914F62@hub.freebsd.org>
Date: Mon, 31 May 1999 10:28:39 -0700 (PDT)
From: delaroca@ucla.edu
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: 3c509b (xl0) ethernet driver unable to map port at kernel load time
X-Send-Pr-Version: www-1.0

>Number:         11961
>Category:       kern
>Synopsis:       3c509b (xl0) ethernet driver unable to map port at kernel load time
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    wpaul
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 31 10:30:01 PDT 1999
>Closed-Date:    Thu Jun 24 16:25:28 PDT 1999
>Last-Modified:  Thu Jun 24 16:27:35 PDT 1999
>Originator:     Denis DeLaRoca
>Release:        3.2
>Organization:
>Environment:
% uname -a
FreeBSD acacia.cts.ucla.edu 3.2-RELEASE FreeBSD 3.2-RELEASE #2: Sun May 30 17:33:36 PDT 1999     root@acacia.cts.ucla.edu:/usr/src/sys/compile/ROSEBUD  i386
% 

>Description:
Below the relevant dmesg output at kernel load time. The 3.1 kernel doesn't exhibit this problem on the identical hardware configuration.

----------------------------------------------------------------------
Probing for devices on PCI bus 0:
chip0: <Host to PCI bridge (vendor=8086 device=7180)> rev 0x03 on pci0.0.0
chip1: <PCI to PCI bridge (vendor=8086 device=7181)> rev 0x03 on pci0.1.0
chip2: <Intel 82371AB PCI to ISA bridge> rev 0x01 on pci0.7.0
ide_pci0: <Intel PIIX4 Bus-master IDE controller> rev 0x01 on pci0.7.1
chip3: <Intel 82371AB Power management controller> rev 0x01 on pci0.7.3
xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x24 int a irq 9 on pci0.14.0
xl0: couldn't map port
xl0: WARNING: this shouldn't happen! Possible PCI support code bug!xl0: attempti
ng to map iobase manuallyxl0: Ethernet address: 00:10:4b:9a:49:a5
xl0: autoneg complete, link status good (half-duplex, 10Mbps)
Probing for devices on PCI bus 1:
vga0: <VGA-compatible display device> rev 0x04 int a irq 9 on pci1.0.0

>How-To-Repeat:
I've no idea if the problem is peculiar to my Micron Millenia PII (300Mhz) machine or whether other systems with 3c509b cards do exhibit this problem as well.
>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: wpaul 
State-Changed-When: Mon May 31 14:36:50 PDT 1999 
State-Changed-Why:  
This happens (I think) because in the BIOS configurationf or your machine, 
you have 'Plug & Play OS' set to 'yes.' For FreeBSD (and LoseNT), it should 
be 'no' because FreeBSD and LoseNT don't have the ability to manually 
fix up the configuration of PCI devices. You need the PCI BIOS to do it, 
then FreeBSD will read the information correctly. 

You'll notice that the driver forges ahead and configures the NIC anyway. 
This is because when pci_map_port() fails, the xl driver tries to read the 
PCI I/O address from the card's PCI config space manually. It shouldn't 
really do that, but it allows the card to work which makes people happy. 
Previously, the driver read the PCI config space by default and didn't 
use pci_map_port() (which was a bug) so nobody noticed that anything was 
wrong. 

Anyway, try this: reboot your machine, and press F2 to get into the CMOS 
setup for your computer. There will probably be a section called 'Advanced' 
and somewhere in there you should find a setting labeled 'Plug and Play OS.' 
It will probably be set to [Yes]. Changed it to [No] (I think you do it by 
pressing the space bar) then press F10 to save the change and exit. Then 
check to see if the NIC is configured correctly without the warning. If  
it works, please let me know, and I will close this PR. 

-Bill 
Responsible-Changed-From-To: freebsd-bugs->wpaul 
Responsible-Changed-By: msmith 
Responsible-Changed-When: Wed Jun 23 17:20:57 PDT 1999 
Responsible-Changed-Why:  
Bill is the xl owner. 
State-Changed-From-To: analyzed->closed 
State-Changed-By: wpaul 
State-Changed-When: Thu Jun 24 16:25:28 PDT 1999 
State-Changed-Why:  

This problem is due to the "Plug and Play OS" setting on the BIOS being 
set to "yes" instead of "no." The latest version of the driver works 
around this, but the correct fix is to change the BIOS setting. 

-Bill 
>Unformatted:
