NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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


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:

The following reply was made to PR kern/36204; it has been noted by GNATS.

From: Wolfgang Stukenbrock <>
To: Masanobu SAITOH <>
Subject: Re: kern/36204 (makphy failed to work on Intel S3000AHLX server board)
Date: Wed, 12 Jun 2013 08:59:36 +0200

yes, we have some ot them but currently all off them are used in
 productive environment - with this interface unused ....
I'm currently preparing an upgrade to 6.1 for all systems and I will
 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
 >>Dr. Nagler & Company GmbH
 >>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
 >>       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 
 >>       I've added some debug output to see what is gooing on, and here is a 
 >>       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 
 >>       Then the startup will setup auto-negotiation and will end up in the 
 >>       setting of the control-registers.
 >>       pscr 0xb60 - pssr 0x6d0c - bmcr 0x1000 epsc 0xd60 anar 0xde1 anap 
 >>       Interpretion:
 >>       pscr - the PSCR_MDI_XOVER_MODE is to 0x3 ?? - not reflected int the 
 >>              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 
 >>       the activity LED indicates some data, but noone seems to get this 
 >>       I've also dump the mii_anegticks and mii_ticks and found a strange 
 >>       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 
 >>       I've replaced the switch with a 10MBit hub, and the interface does 
 >>       to 10MBit, hdx and works fine. Packets are send and recieved as 
 >>       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 
 >>       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 
 >>       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 
 >>       but I've no datasheets etc..
 >>       I've alreay looked into the FreeBSD implementation and tried some 
 >>       from there without success. (e.g. other clock-bit setting)
 >>       Try to run the wm0 on S3000AHLX server board ...
 >>       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
 Hauptstra?e 9
 92253 Schnaittenbach
Tel. +49 9622/71 97-42
 Fax +49 9622/71 97-50
Hauptsitz: Schnaittenbach
 Handelregister: Amberg HRB
 Gerichtsstand: Amberg
 Steuernummer: 201/118/51825
 USt.-ID-Nummer: DE 273143997
 Gescha"ftsfu"hrer: Dr. Martin Nagler, Prof. Dr. Dr. Karl-Kuno Kunze


Dr. Nagler & Company GmbH
Hauptstraße 9
92253 Schnaittenbach

Tel. +49 9622/71 97-42
Fax +49 9622/71 97-50

Hauptsitz: Schnaittenbach
Handelregister: Amberg HRB
Gerichtsstand: Amberg
Steuernummer: 201/118/51825
USt.-ID-Nummer: DE 273143997
Geschäftsführer: Dr. Martin Nagler, Prof. Dr. Dr. Karl-Kuno Kunze

Home | Main Index | Thread Index | Old Index