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)



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

From: Masanobu SAITOH <msaitoh%execsw.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: Wolfgang Stukenbrock <wolfgang.stukenbrock%nagler-company.com@localhost>, 
 msaitoh%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost, 
 msaitoh%execsw.org@localhost
Subject: Re: kern/36204 (makphy failed to work on Intel S3000AHLX server board)
Date: Fri, 14 Jun 2013 11:20:00 +0900

 Hi.
 
 (2013/06/13 18:40), Wolfgang Stukenbrock wrote:
 > The following reply was made to PR kern/36204; it has been noted by GNATS.
 > 
 > From: Wolfgang Stukenbrock 
 > <wolfgang.stukenbrock%nagler-company.com@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: msaitoh%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
 > netbsd-bugs%NetBSD.org@localhost
 > Subject: Re: kern/36204 (makphy failed to work on Intel S3000AHLX server 
 > board)
 > Date: Thu, 13 Jun 2013 11:38:38 +0200
 > 
 >   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.
 
  I think it's not important to verify in 6.1.
 
 
 >   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.
 
  Thanks. I'll close this 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 
 > <wolfgang.stukenbrock%nagler-company.com@localhost>
 >   > To: Masanobu SAITOH <msaitoh%execsw.org@localhost>
 >   > Cc: gnats-bugs%NetBSD.org@localhost, msaitoh%NetBSD.org@localhost, 
 > kern-bug-people%NetBSD.org@localhost,
 >   >         netbsd-bugs%NetBSD.org@localhost, 
 > gnats-admin%NetBSD.org@localhost
 >   > Subject: Re: kern/36204 (makphy failed to work on Intel S3000AHLX server 
 > board)
 >   > Date: Wed, 12 Jun 2013 08:59:36 +0200
 >   >
 >   >  Hi,
 >   >
 >   >  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
 >   >  >>>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
 >   >  Hauptstra?e 9
 >   >  92253 Schnaittenbach
 >   >
 >   >  Tel. +49 9622/71 97-42
 >   >  Fax +49 9622/71 97-50
 >   >
 >   >  Wolfgang.Stukenbrock%nagler-company.com@localhost
 >   >  http://www.nagler-company.com
 >   >
 >   >
 >   >  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
 >   
 >   Wolfgang.Stukenbrock%nagler-company.com@localhost
 >   http://www.nagler-company.com
 >   
 >   
 >   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
 >   
 >   
 > 
 
 
 -- 
 -----------------------------------------------
                 SAITOH Masanobu (msaitoh%execsw.org@localhost
                                  msaitoh%netbsd.org@localhost)
 



Home | Main Index | Thread Index | Old Index