From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 01:26:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36912531; Tue, 11 Jun 2013 01:26:38 +0000 (UTC) (envelope-from clif@eugeneweb.com) Received: from eugeneweb.com (eugeneweb.com [149.20.56.103]) by mx1.freebsd.org (Postfix) with ESMTP id 16A891EF6; Tue, 11 Jun 2013 01:26:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by eugeneweb.com (Postfix) with ESMTP id 4B69124C101; Mon, 10 Jun 2013 18:26:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at eugeneweb.com Received: from eugeneweb.com ([127.0.0.1]) by localhost (eugeneweb.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eskFwlP49WGe; Mon, 10 Jun 2013 18:26:36 -0700 (PDT) Received: from [192.168.0.1] (unknown [71.193.185.189]) by eugeneweb.com (Postfix) with ESMTP id AEE3A24C0FF; Mon, 10 Jun 2013 18:26:35 -0700 (PDT) Message-ID: <51B67CCA.2010507@eugeneweb.com> Date: Mon, 10 Jun 2013 18:26:34 -0700 From: "Mr. Clif" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130119 Firefox/10.0.11esrpre Iceape/2.7.12 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <51A6CE52.20501@eugeneweb.com> <20130530051214.GA1530@michelle.cdnetworks.com> <201305300929.31872.jhb@freebsd.org> <51B62547.5000207@eugeneweb.com> <20130611002848.GA1519@michelle.cdnetworks.com> In-Reply-To: <20130611002848.GA1519@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 01:26:38 -0000 Is there any down side to using that dc fix in pfsense for now? Yes, I would like to have time to submit the cas bug as well. Maybe in the next week but probably by august I hope. ;-) Thanks for your help, Clif YongHyeon PYUN wrote: > On Mon, Jun 10, 2013 at 12:13:11PM -0700, Mr. Clif wrote: >> Hi John and Pyun, >> >> Ok got the new kernel installed and tested. Yes it works! :-) Maybe that > Thanks, probably John can fix PCI-PCI bridge code. > >> will also fix a simular problem with the sun cards (cas[03]), except I >> don't see a define like that in if_cas.c. Suggestions? > Cassini does not support I/O port BARs so I guess you're seeing > different issue. Would you start a new thread that explains cas(4) > issues you're suffering from? > >> Thanks, >> Clif >> >> >> John Baldwin wrote: >>> On Thursday, May 30, 2013 1:12:14 am YongHyeon PYUN wrote: >>>> On Wed, May 29, 2013 at 08:58:10PM -0700, Mr. Clif wrote: >>>>> Sorry for the confusion Pyun, >>>>> >>>>> I started looking at it in the context of pfsense, but they rejected my >>>>> bug report which was understandable because it's an upstream issue. They >>>>> suggested I resubmit it to you guys if I could reproduce it. So I booted >>>>> FreeBSD and lo and behold the same two ports failed in exactly the same >>>> Ok, I'd like to fix that. >>> Hmmm, the dc(4) driver is using the I/O port BARs rather than the >>> memory BARs for its registers and this bug seems to be that the dc(4) >>> device can't properly access its registers on dc0 and dc1 on the >>> Atom box. The one thing I see is that the BIOS on the Atom box assigns >>> addresses in the 0x1100-0x11ff range for dc0 and dc1. Those addresses >>> conflict with ISA I/O aliases for the 0x100-0x1ff range. The Dell BIOS >>> is more careful to avoid these ranges. >>> >>> I think the fix is that I need to fix the PCI-PCI bridge to reject these >>> resource ranges if the ISA enable bit is set in the bridge's control >>> register. However, for the time being you can change dc(4) to use the >>> memory BAR instead of the I/O port BAR as a workaround: >>> >>> Index: if_dc.c >>> =================================================================== >>> --- if_dc.c (revision 251132) >>> +++ if_dc.c (working copy) >>> @@ -128,7 +128,7 @@ __FBSDID("$FreeBSD$"); >>> #include >>> #include >>> >>> -#define DC_USEIOSPACE >>> +//#define DC_USEIOSPACE >>> >>> #include >>> >>> >>> If this fixes it then I can take this PR as a test case for handling the >>> ISA >>> enable bit in the PCI-PCI bridge code. >>>