Subject: Re: network problem with netra t1 105
To: matthew green <mrg@eterna.com.au>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: port-sparc64
Date: 10/17/2001 08:59:59
On Wed, Oct 17, 2001 at 08:17:18AM -0700, Jason R Thorpe wrote:

 > The reason for not seeing the second HME is probably an artifact of
 > the PCI "devorder" stuff that the sparc64 port uses -- that's just a
 > guess anyway ... Solaris obviously sees the second HME at device 3,
 > but NetBSD isn't for whatever reason, and the PCI "devorder" stuff is
 > the only thing that pops immediately to mind.

Ok, I think I've figured this part out, too.  Examine the Solaris
dmesg output again -- note that both HME devices are at function 1
of their respective PCI devices.  The first one is at function 1 of
the "ebus" bridge, that is:

	ebus	1,0
	hme	1,1

The second HME is at 3,1 ... but I don't see anything at 3,0.  This is
the problem -- the NetBSD PCI enumeration code checks to see if there
is a valid PCI header at function 0, and then checks for additional
functions if that header indicates that the device is a multi-function
device.  Since there is no valid header at 3,0, 3,1 will never be
consulted.  Sun needs a bonk on the head for this one (I'd have to
double-check the spec, but I'm pretty Sun did the Wrong Thing as far as
PCI is concerned).

I think the PCI "devorder" stuff will need to be changed to deal with
this ... specifically, instead of indicating the order with which to
do the normal probe, it should probably get a list of dev,func tuples
at which to find a device, and consult only those locations.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>