Mon, Jul 15, 2002 at 12:19:07PM -0700, Jason R Thorpe:
> On Mon, Jul 15, 2002 at 11:25:26AM -0700, john heasley wrote:
> 
>  > i suspect that you have both ukphy and nsphy PHYs in your kernel and
>  > your hme's got hooked to the ukphy PHY.  try building a kernel without
>  > ukphy.
> 
> Having both nsphy and ukphy in a kernel will not cause this lossage.
> 
> In fact, ukphy will ONLY match a PHY if no other, more specific, driver
> does.

that is what i thought was supposed to happen; perhaps memory is hazy.
i thought nsphy had matched it a while back.

booting a 1.6D kernel with ukphy:
hme0 at pci1 dev 1 function 1: Sun Happy Meal Ethernet, rev. 1
hme0: interrupting at ivec 3021
hme0: Ethernet address 08:00:20:d9:1c:68
ukphy0 at hme0 phy 0: Generic IEEE 802.3u media interface
ukphy0: OUI 0x0006b8, model 0x000c, rev. 1
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ukphy1 at hme0 phy 1: Generic IEEE 802.3u media interface
ukphy1: OUI 0x0006b8, model 0x000c, rev. 1
ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

hme1 at pci1 dev 3 function 1: Sun Happy Meal Ethernet, rev. 1
hme1: interrupting at ivec 301a
hme1: Ethernet address 08:00:20:d9:1c:68
ukphy2 at hme1 phy 0: Generic IEEE 802.3u media interface
ukphy2: OUI 0x0006b8, model 0x000c, rev. 1
ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

which now exhibits the problem that ji@att describes; maybe attributed
to the dual OUI you mentioned (i'm not hip on how the inards work and
didnt think much of the double OUI when i saw it; though it might be an
MII intf on the chip, though no MII connector exists on the back of the
box).

i've seen this on another discrete pci hme board in my ultra II (a clone).
it'd be another day or so before i can re-rack it and get .properties.

> The fact that nsphy does not match is an indication that the PHY is
> not a National Semiconductor PHY.  The OUI you provide seems to provide
> further evidence of this:
> 
>  > hme0 at pci1 dev 1 function 1: Sun Happy Meal Ethernet, rev. 1
>  > hme0: interrupting at ivec 3021
>  > hme0: Ethernet address 08:00:20:d9:1c:68
>  > OUI 0x0006b8 model 0x000c rev 1 at hme0 phy 0 not configured
>  > OUI 0x0006b8 model 0x000c rev 1 at hme0 phy 1 not configured
>  > 
>  > hme1 at pci1 dev 3 function 1: Sun Happy Meal Ethernet, rev. 1
>  > hme1: interrupting at ivec 301a
>  > hme1: Ethernet address 08:00:20:d9:1c:68
>  > OUI 0x0006b8 model 0x000c rev 1 at hme1 phy 0 not configured
> 
> So, that OUI is not listed in sys/dev/mii/miidevs.  You definitely
> should be using the "ukphy" driver, as it will attach to it and
> attempt to use it in a generic way.
> 
> The issue with the first hme seeing two PHYs is somewhat of a concern; I
> am wondering if the two HME devices are sharing the serial bus which is
> used to do PHY management.

both hme's are built-in on the t1/105.  i dont know how other netras are
equipped.

> ji -- can you provide full boot messages captured from the serial
> console?  Also, ".properies" dumps of the OpenFirmware nodes for
> the HME devices night be helpful.

this is from my T1/105.  i think this accounts for both hmes:

ok pwd
/pci@1f,0/pci@1/pci@1/ethernet@f
ok .properties
latency-timer            00000008 
assigned-addresses       c2037810 00000000 00100000 00000000 00001000 
                         81037814 00000000 00001040 00000000 00000020 
                         82037818 00000000 00200000 00000000 00100000 
reg                      00037800 00000000 00000000 00000000 00000000 
                         42037810 00000000 00000000 00000000 00001000 
                         01037814 00000000 00000000 00000000 00000020 
                         02037818 00000000 00000000 00000000 00100000 
compatible               pci8086,1
                         pci8086,1229
                         pciclass,020000
name                     ethernet
fast-back-to-back 
devsel-speed             00000001 
class-code               00020000 
interrupts               00000001 
max-latency              00000038 
min-grant                00000008 
subsystem-vendor-id      00008086 
subsystem-id             00000001 
revision-id              00000002 
device-id                00001229 
vendor-id                00008086 

thanks, jason!

>  > 
>  > Fri, Jul 12, 2002 at 12:04:14AM -0400, ji@research.att.com:
>  > > In short: the driver sends out packets, but it can't receive. 
>  > > 
>  > > I'm trying to install netbsd/sparc64 on an old netra t1.  Aside from the 
>  > > problem with ifconfig that I reported earlier, I noticed that the driver
>  > > itself doesn't quite work.  It sends out packets (I can see them with
>  > > tcpdump), but it does not appear to be receiving; it does not respond to
>  > > pings, and does not even receive the arp replies to the arps it sends out.
>  > > 
>  > > openbsd-current has the same problem with the driver (but not with ifconfig).
>  > > 
>  > > /ji
> 
> -- 
>         -- Jason R. Thorpe <thorpej@wasabisystems.com>