From owner-freebsd-current@FreeBSD.ORG Fri Dec 29 11:19:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5652516A4B3 for ; Fri, 29 Dec 2006 11:19:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id EEE0913C455 for ; Fri, 29 Dec 2006 11:19:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so4591856wxc for ; Fri, 29 Dec 2006 03:19:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=nJStmY2qVLsCvSNmGP3xDv0s7iRhmYH9Snqq0A4oL6HzcqSxQ2J1R1+++ApfIoVTmDW6X4JYNMQKGKGumn+m1RiqhGKHABDqmNDcrbTkwSBiKhpFCxvG+skT3a16JpR5C8WreB0hIu98WOF3VMjj+sqfcwHmWbMSBexcPu+hZek= Received: by 10.70.99.9 with SMTP id w9mr13484249wxb.1167365237732; Thu, 28 Dec 2006 20:07:17 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 7sm31694570wrh.2006.12.28.20.07.14; Thu, 28 Dec 2006 20:07:17 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id kBT466Ju014514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Dec 2006 13:06:06 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id kBT464D6014513; Fri, 29 Dec 2006 13:06:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 29 Dec 2006 13:06:03 +0900 From: Pyun YongHyeon To: John Baldwin Message-ID: <20061229040603.GA13696@cdnetworks.co.kr> References: <20061212020023.GA9698@cdnetworks.co.kr> <4590A575.3090403@samsco.org> <20061226072929.GC994@cdnetworks.co.kr> <200612281550.55581.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612281550.55581.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, "Bruce M. Simpson" Subject: Re: Enabling MSI on the Asus Vintage AH-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2006 11:19:31 -0000 On Thu, Dec 28, 2006 at 03:50:54PM -0500, John Baldwin wrote: > On Tuesday 26 December 2006 02:29, Pyun YongHyeon wrote: > > On Mon, Dec 25, 2006 at 11:30:45PM -0500, Scott Long wrote: > > > Pyun YongHyeon wrote: > > > >On Sat, Dec 23, 2006 at 09:54:58PM +0000, Bruce M. Simpson wrote: > > > > > Hi, > > > > > > > > > > It looks like MSI was detected, but not used by the msk(4) driver on > > > > the > Asus Vintage AH-1. > > > > > > > > > > This is a uniprocessor Athlon64 system. The PCI bridges on this system > > > > > aren't in the MSI blacklist, however, there are several odd messages > > > > > regarding a non-default MSI window. Looking at the code suggests it > > > > > expects to see the MSI window at 0xfee00000. > > > > > > > > > > BTW: This system's on-board SATA controller stopped working with > > > > 6.2-RC, > so I'm using an add-on PCI-e card for SATA to connect the root > > > > disk. > > > > > > > > > > pcib0: port 0xcf8-0xcff on acpi0 > > > > > pci0: on pcib0 > > > > > pci0: physical bus=0 > > > > > > > >[...] > > > > > > > > > pcib2: at device 6.0 on pci0 > > > > > pcib2: secondary bus 2 > > > > > pcib2: subordinate bus 2 > > > > > pcib2: I/O decode 0xc000-0xcfff > > > > > pcib2: memory decode 0xfe400000-0xfe4fffff > > > > > pcib2: no prefetched decode > > > > > pci2: on pcib2 > > > > > pci2: physical bus=2 > > > > > found-> vendor=0x11ab, dev=0x4362, revid=0x19 > > > > > bus=2, slot=0, func=0 > > > > > class=02-00-00, hdrtype=0x00, mfdev=0 > > > > > cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords) > > > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > > > intpin=a, irq=5 > > > > > powerspec 2 supports D0 D1 D2 D3 current D0 > > > > > VPD Ident: Marvell Yukon 88E8053 Gigabit Ethernet Controller > > > > > PN: Yukon 88E8053 > > > > > EC: Rev. 1.9 > > > > > MN: Marvell > > > > > SN: AbCdEfG32a88a > > > > > CP: id 1, BAR16, off 0x3cc > > > > > RV: 0x24 > > > > > MSI supports 2 messages, 64 bit > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >I think Yukon II supports one MSI message. But all systems I know > > > >reported that it supports two MSI messages. This is main reason why > > > >msk(4) doesn't use MSI ATM. I don't know why Yukon II claims to > > > >support two MSI messages.(for dual port MAC configuraiton?) > > > > > > My guess is that it advertises 2 messages for the dual-port > > > configuration. The intention is probably that the driver would > > > run a loop where it allocates a message as it configures each port. > > > So if you only have a single port, then you only allocate a single > > > message and ignore the other one. This looks like it will be hard to > > > fit into the msk+mskc code that is there right now. > > > > > > > > > > >You can force to use MSI by assigning 'msic = 1' before calling > > > >pci_alloc_msi(9) in mskc_attach(). However it wouldn't work if you > > > >reload the msk(4) again. Other than that it works well with MSI. > > > > > > I don't understand why there would be a failure here. Can you explain? > > > > > > > Me too. > > > > I don't remember what message it was but it's somthing like > > a message with two irq numbers for the device on second loading > > and then it failed to allocate interrupt handler. > > > > mskc0: port 0xXXXX-0xYYYY mem > > 0xXXXXXXXX-0xYYYYYYYY irq 19, 256 at device X.Y on pciX > > ^^^^^^^^^^^ > > You need to do the pci_release_msi() after releasing the SYS_RES_IRQ resource. > Also, to support MSI-X parts, you need to alloc your SYS_RES_MEMORY resource > before you call pci_alloc_msi(). The patch below fixes much of this, but > disables MSI for the dual port cards for now since I didn't want to untangle > all the interrupt code to create separate MSI handlers for each port. You > also have a bug in your task where it seems that if you ifconfig the first > port on a dual port card down, you won't ever handle interrupts for the > second port: > > if (sc_if0 != NULL) { > ifp0 = sc_if0->msk_ifp; > if ((ifp0->if_drv_flags & IFF_DRV_RUNNING) == 0) > goto done; > } > if (sc_if1 != NULL) { > ifp1 = sc_if1->msk_ifp; > if ((ifp1->if_drv_flags & IFF_DRV_RUNNING) == 0) > goto done; > } > > Since RUNNING would be clear for ifp0, you would goto done and not handle Possible fix committed. Needs more testing for dual port card. > any of the events for ifp1. Anyways, here is the patch I came up with so > far: > Thank you very much for taking care of this! Patch committed. -- Regards, Pyun YongHyeon