Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 01 Dec 2006 20:34:32 -0700
From:      Scott Long <scottl@samsco.org>
To:        Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw>
Cc:        Pyun YongHyeon <pyunyh@gmail.com>, freebsd-current@freebsd.org
Subject:   Re: Call for e1000phy(4) testers.
Message-ID:  <4570F448.6040007@samsco.org>
In-Reply-To: <0612021130107.1887@www.mmlab.cse.yzu.edu.tw>
References:  <20061128115538.GB66517@cdnetworks.co.kr> <0612011540189.97361@www.mmlab.cse.yzu.edu.tw> <456FE143.7040206@samsco.org> <0612021130107.1887@www.mmlab.cse.yzu.edu.tw>

next in thread | previous in thread | raw e-mail | index | archive | help
Tai-hwa Liang wrote:

> On Fri, 1 Dec 2006, Scott Long wrote:
> 
>> Tai-hwa Liang wrote:
>> > On Tue, 28 Nov 2006, Pyun YongHyeon wrote:
>> >> Hi,
>> >>
>> >> I had been writing msk(4) for FreeBSD and realized that e1000phy(4)
>> >> is buggy on newer Marvell PHYs. For example, manual media selection
>> >> didn't work at all and I had to stick to autoselection of the media
>> >> type. The Marvell PHYs are widely used on various NICs including
>> >> em(4), stge(4), sk(4), msk(4) and nfe(4). Except em(4) which does
>> >> not support MII layers, correct operation of e1000phy(4) is very
>> >> important to get a good link with link partner and to report link
>> >> state changes to upper layers(e.g. dhclinet(8)).
>> > >   Thank you for working on this.
>> > >> With this patch you should be able to set a media type without
>> >> relying on autoselection and it should supports automatic crossover
>> >> for all known Marvell PHYs. I've tried hard not to break existing
>> >> behaviour(e.g. Fiber transceivers) but I can't verify that as I
>> >> don't have any NICs that have Marvell Fiber transceivers. The patch
>> >> is somewhat ugly in that it should read a PHY ID register in several
>> >> palces. It seems that there is no easy way to avoid the reading until
>> >> we have PHY model/revision numbers in mii softc.
>> >>
>> >> If you are one of users that use stge(4), sk(4), msk(4) and nfe(4)
>> >> please test and report any strange things not observed on stock
>> >> version.
>> >>
>> >> Note for nfe(4) users:
>> >> It seems that nfe(4) has bugs that it can't send packets on
>> >> half-duplex media(I've got "tx v1 error 0x6004"). I guess this comes
>> >> from mismatches between PHY and MAC. So you may have to set
>> >> full-duplex on nfe(4) until we have a fix for the issue.
>> >>
>> >> You can get the latest e1000phy(4) driver from the following URL.
>> >> http://people.freebsd.org/~yongari/msk/e1000phy.c
>> >> http://people.freebsd.org/~yongari/msk/e1000phyreg.h
>> >> http://people.freebsd.org/~yongari/msk/miidevs
>> >>
>> >> OR get a jumbo patch for CURRENT.
>> >> http://people.freebsd.org/~yongari/msk/e1000phy.patch
>> > >   I have tried your e1000phy patch as well as msk.diff.HEAD on an 
>> Acer
>> > Aspire 5583 WXMi laptop:
>> > > mskc0@pci2:0:0:    class=0x020000 card=0x01101025 chip=0x435211ab 
>> > rev=0x14 hdr=0x00
>> >     vendor   = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
>> >     class    = network
>> >     subclass = ethernet
>> > >   It seems that device_attach always returns 6 regardless > 
>> hw.pci.enable_msi[x]
>> > is 1 or 0:
>> > > mskc0: <Marvell Yukon 88E8038 Gigabit Ethernet> irq 10 at device 
>> 0.0 on > pci2
>> > mskc0: MSI count : 2
>> > pcib2: mskc0 requested unsupported memory range 0-0xffffffff 
>> (decoding > 0-0, 0-0)
>> > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
>> > mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000
>> > mskc0: unknown device: id=0xff, rev=0x0f
>> > device_attach: mskc0 attach returned 6
>> >
>> This is a resource allocation problem with the PCI BAR on the card. 
>> Either your BIOS isn't setting it up correctly, or FreeBSD is doing
>> something freakishly wrong.  Does your BIOS have a switch for 'Plug N 
>> Play OS" or something to that effect?
> 
> 
>   Nope.  FWIW, it is PhoenixBIOS 4.0 Release 6.1, v1.3211.
> 

Well, you're going to have to bug Warner and John to improve the lazy
resource allocation scheme to cover this.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4570F448.6040007>