Re: kern/36204 (makphy failed to work on Intel S3000AHLX server board)

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

>>Number:         36204
>>Category:       kern
>>Synopsis:       makphy failed to work on Intel S3000AHLX server board
>>Confidential:   no
>>Severity:       serious
>>Priority:       medium
>>Responsible:    msaitoh
>>State:          open
>>Class:          sw-bug
>>Submitter-Id:   net
>>Arrival-Date:   Tue Apr 24 10:50:00 +0000 2007
>>Last-Modified:  Wed Jun 12 02:39:32 +0000 2013
>>Originator:     Wolfgang Stukenbrock
>>Release:        NetBSD current
>>Organization:
> Dr. Nagler & Company GmbH
> 
>       
>>Environment:
> 
>       
> 
>       
> System: NetBSD test-s0 3.1 NetBSD 3.1 (test-s0) #0: Tue Apr 3 11:33:43 CEST 
> 2007 root@test-s0:/usr/src/sys/arch/i386/compile/test-s0 i386
> Architecture: i386 / amd64
> Machine: i386 / amd64
>>Description:
>       There are two onbaord Gbit-Interfaces on this server board:
>       wm0 at pci4 dev 0 function 0: Intel i82573E  IAMT, rev. 3
>       wm1 at pci5 dev 5 function 0: Intel i82541GI 1000BASE-T Ethernet, rev. 5
>       The i82541GI has an igphy and works fine.
>       The i82573E has a makphy and fails to establisch connections to the 
> network.
>       I've added some debug output to see what is gooing on, and here is a 
> short
>       discription of what I've seen:
>       After the system ahs booted the iterface will be reset (reset command 
> in BMCR).
>       Before reset it has the value 0x1140 and will be set to 0x0 after reset.
>       Then the startup will setup auto-negotiation and will end up in the 
> following
>       setting of the control-registers.
>       pscr 0xb60 - pssr 0x6d0c - bmcr 0x1000 epsc 0xd60 anar 0xde1 anap 0x45e1
>       Interpretion:
>       pscr - the PSCR_MDI_XOVER_MODE is to 0x3 ?? - not reflected int the 
> headerfile.
>              I've also tried 0x2 - documented for AUTO without success
>              The PSCR_MBO is 0 - coment "must be one" ???
>              PSCR_CRS_ON_TX set - as done in the reset code (change from 3.1 
> to current)
>              The bits 8 and 9 are both set - not ducumented in headerfile are 
> set. This
>              are energie mode bits in the FreeeBSD implementation ...
>       pssr - The PHY report sucessfull link up with MDI 100TX fdx
>              speed and duplex are indicated as resolved.
>              cable length is 0x2 - whatever this means ...
>              some other (unknown to the headerfile) bits are set.
>       bmcr - set to BMCR_AUTOEN
>       anar - looks good
>       anap - some information about the partner is retrieve - looks good
>       epsc - ??? EPSC_TX_CLK = 0xd6 if it has so much bits ...
> 
> 
>       The link LED in the switch is on and if packets are send to the network
>       the activity LED indicates some data, but noone seems to get this data.
>       I've also dump the mii_anegticks and mii_ticks and found a strange 
> behavior,
>       but I think this is another bug or feature of makphy.c.
>       mii_anegticks is set to 10 (because the interface can do 1000).
>       I've places a kernel-printf in the status routine and mii_ticks starts 
> 0 on boot,
>       will reach 3 after auto-neg.
>       If I do a "ifconfig wm0 media auto" mii_ticks gets incremented by 2 or 
> 3 each time
>       the comand is issued. A reset of the interface is done after it has 
> reached 10.
>       I think there is a reset of mii_ticks ticks missing when starting 
> auto-neg.
> 
> 
>       I've replaced the switch with a 10MBit hub, and the interface does 
> auto-neg
>       to 10MBit, hdx and works fine. Packets are send and recieved as 
> expected.
>       The same will happen if I connect the 100MBit switch again and use
>       "ifconfig wm0 media utp", "ifconfig wm0 media utp mediaopt fdx" or
>       "ifconfig wm0 media utp mediaopt fdx,flow". The interface works.
>       Here the setting of the registers of theese three settings in that 
> order:
>       pscr 0xb60 - pssr 0xd00 - bmcr 0x0 epsc 0xd60 anar 0x21 anap 0x0
>       pscr 0xb60 - pssr 0x2d00 - bmcr 0x100 epsc 0xd60 anar 0x41 anap 0x0
>       pscr 0xb60 - pssr 0x2d00 - bmcr 0x100 epsc 0xd60 anar 0xc41 anap 0x0
>       The speed and mediaopt settings are reflectd in anar but no information
>       is recieved from the peer! is this OK ???????
> 
> 
>       No communication will be established useing 100tx instead of utp.
>       Here is the debug output again for that:
>       pscr 0xb60 - pssr 0x4d00 - bmcr 0x2000 epcr 0xd60 anar 0x81 anap 0x0
>       pscr 0xb60 - pssr 0x6d00 - bmcr 0x2100 epcr 0xd60 anar 0x101 anap 0x0
>       pscr 0xb60 - pssr 0x6d40 - bmcr 0x2100 epcr 0xd60 anar 0xd01 anap 0x0
>       Again no anap information is retrieved - bmcr, anar looks good to me.
>       pssr: "link up" is reported, but no communication can be done ...
>             speed and duplex mode look good
> 
> 
>       I've tried the following version of makphy.c:
>       $NetBSD: makphy.c,v 1.23 2007/02/23 03:03:10 msaitoh Exp $
> 
> 
>       I need to get it up and are willing to spend additional time in 
> debugging,
>       but I've no datasheets etc..
>       I've alreay looked into the FreeBSD implementation and tried some 
> varaints
>       from there without success. (e.g. other clock-bit setting)
>>How-To-Repeat:
>       Try to run the wm0 on S3000AHLX server board ...
>>Fix:
>       Not known to me up to now.
>       If some have a datasheet for this PHY, I will help to locate
>       the problem.

 Do you still have the box? I suspect this problem was fixed.


-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)