Hi,
it would take some till I get 6.1 ready here - sorry.
But I've a look at our runnning systems.
It looks like that the interface now works.
I've seen it running in some of our 5.1.2 Installations.

In 4.x it looks still broken - at least all systems with that release do
not use this interface.

My 5.1.2 version includes updates from current for if_wm.c and some phy,
so I cannot say if it is fixed in the release itself.

Because I've done no own changes to the phy-implementations - just
updates from current with sometime backporting due to kernelchanges -
there is a working version of makphy for this board in current available.

If you want a commitment that it works in 6.1. release, you have to wait
some time.
At the moment if_wm.c and all phy-implementation is from 6.1-release in
my 6.1 version. (That my change, if the ipsec processing related
MP-locking problem has not been solved in 6.1 - a different aproach as
mine has been integrated there ...)

Otherwise I think you can close this old PR.
best regards
W. Stukenbrock
Wolfgang Stukenbrock wrote:

have a look at this as soon as I get to a system with this board.
At least in 4.x the problem was still there.

best regards
W. Stukenbrock
Masanobu SAITOH wrote:
>>>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.
>
>
>
--
Dr. Nagler & Company GmbH