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