Date: Tue, 8 Jul 2008 15:24:43 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Krzysztof J??druczyk <beaker@hot.pl> Cc: freebsd-stable@freebsd.org Subject: Re: Marvell Yukon 88E8062 - media selection problem Message-ID: <20080708062443.GE12415@cdnetworks.co.kr> In-Reply-To: <487263EF.6070003@hot.pl> References: <20080701004855.GF83626@cdnetworks.co.kr> <486A07A4.1070406@hot.pl> <20080702010929.GA87933@cdnetworks.co.kr> <486C0E69.8020603@hot.pl> <20080703015948.GB92015@cdnetworks.co.kr> <486CBA1D.6000602@hot.pl> <20080705011612.GC671@cdnetworks.co.kr> <48712EE8.1000701@hot.pl> <20080707102433.GE8171@cdnetworks.co.kr> <487263EF.6070003@hot.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 07, 2008 at 08:43:59PM +0200, Krzysztof J??druczyk wrote: > Pyun YongHyeon wrote: > >Since the patch had lots of code not related with 88E8062 dual port > >controller, would you try attached patch again? I think the attached > >patch is minimal one that makes 88E8062 work. > > > >The patch also try to enable MSI for dual port controllers. At the > >time of writing support for MSI I had no testers to experiment MSI so > >MSI on dual port controllers were ignored. Please see if msk(4) take > >advantage of MSI. irq256 or higher number would be showed in "vmstat > >-i" output if MSI is active. > > > # vmstat -i > interrupt total rate > irq14: ata0 1450 1 > irq16: fxp0 uhci0 2058 1 > cpu0: timer 2705189 1999 > irq256: mskc0 92 0 > cpu1: timer 2704883 1999 > Total 5413672 4001 > > I guess MSI is enabled. > That's great! > As of the results of tests I'm not sure what to start with... Initially > both interfaces seemed non-functional with nothing getting transmitted > to other machine. Then I noticed that it seems that msk1 seemed to > receive packets that should be on msk0 (?): > > ># tcpdump -i msk1 > >tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > >listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes > >20:28:41.757722 arp who-has 192.168.0.1 tell 192.168.0.2 > > 192.168.0.2 is on em0 on other machine, and should be on the same switch > as msk0. At least this was the case on previous tests in which both > interfaces worked... > > Another time on the same test corrupted data was received: > > >tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > >listening on msk1, link-type EN10MB (Ethernet), capture size 96 bytes > >20:31:29.806041 d3:04:ff:ff:ff:ff (oui Unknown) > 22:a0:00:00:02:f0 (oui > >Unknown), ethertype Unknown (0x3cc0), length 60: > > 0x0000: de07 0000 0000 0000 0000 0000 0000 0000 ................ > > 0x0010: 0000 ffff ffff ffff 0002 0406 0800 0806 ................ > > 0x0020: 0001 0800 0604 0001 0002 0406 0800 .............. > > And later magically the msk1 <-> em0 link started working... Seems to > work just fine after reboot (I didn't try to power down machine, just > shutdown -r). > > So to sum up - in the end mks1 interface worked in some weird way - but > it seemed to represent the link that was under msk0 previously. It may still have some odd cases for dual port controllers. I guess the reset sequence of the controller is important as status LEs are shared between ports. The patch you tried in previous patch( msk.88E8040.patch5) has a couple of fixes which might also help to stability under certain conditions. Orignally msk.88E8040.patch5 was generated for 88E8040 fast ethernet controller but it miserably failed to support the controller so I had to think harder to make it work. :-( Anyway I'll commit the minimal patch in a couple of days as it seems that it wouldn't affect other Yukon II controllers. Thanks a lot for your time and testing! -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080708062443.GE12415>