From owner-freebsd-stable@FreeBSD.ORG Mon Jul 7 19:00:53 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34ED31065674 for ; Mon, 7 Jul 2008 19:00:53 +0000 (UTC) (envelope-from beaker@hot.pl) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E74CE8FC1B for ; Mon, 7 Jul 2008 19:00:52 +0000 (UTC) (envelope-from beaker@hot.pl) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 8EB75138443; Mon, 7 Jul 2008 14:44:00 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 07 Jul 2008 14:44:00 -0400 X-Sasl-enc: KAlfHiwRZ79uVSR9RtsQa9ey3o1zm1PoUmEg1bAK1sVt 1215456240 Received: from buka.ramfasto.com (dyb186.internetdsl.tpnet.pl [83.14.53.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D6B413F43; Mon, 7 Jul 2008 14:43:59 -0400 (EDT) Message-ID: <487263EF.6070003@hot.pl> Date: Mon, 07 Jul 2008 20:43:59 +0200 From: =?UTF-8?B?S3J6eXN6dG9mIErEmWRydWN6eWs=?= User-Agent: Thunderbird 2.0.0.14 (X11/20080707) MIME-Version: 1.0 To: pyunyh@gmail.com References: <1052423937.20080630135423@hot.pl> <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> In-Reply-To: <20080707102433.GE8171@cdnetworks.co.kr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Marvell Yukon 88E8062 - media selection problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 19:00:53 -0000 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. 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. -- Best regards, Krzysztof Jędruczyk