Date: Tue, 10 Feb 2009 09:50:02 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Gary Jennejohn <gary.jennejohn@freenet.de> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pyun YongHyeon <yongari@freebsd.org> Subject: Re: svn commit: r188381 - head/sys/dev/re Message-ID: <20090210005002.GD98095@michelle.cdnetworks.co.kr> In-Reply-To: <20090209181056.40db0ba2@ernst.jennejohn.org> References: <200902090459.n194xDa3045928@svn.freebsd.org> <20090209181056.40db0ba2@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--tEFtbjk+mNEviIIX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 09, 2009 at 06:10:56PM +0100, Gary Jennejohn wrote: > On Mon, 9 Feb 2009 04:59:13 +0000 (UTC) > Pyun YongHyeon <yongari@FreeBSD.org> wrote: > > > Author: yongari > > Date: Mon Feb 9 04:59:13 2009 > > New Revision: 188381 > > URL: http://svn.freebsd.org/changeset/base/188381 > > > > Log: > > Reclaim transmitted frames in re_tick(). This is for PCIe > > controllers that lose Tx completion interrupts under certain > > conditions. With this change it's safe to use MSI on PCIe > > controllers so enable MSI on these controllers. > > > > Modified: > > head/sys/dev/re/if_re.c > > > > This does not work with my re(4). When I allow MSI it never transmits. > I noticed this while booting when the sendmail startup hung. A test > with ping(8) showed that there was no output (or maybe no input, hard > to tell with ping). > > Here dmesg output when it fails: > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet> port 0xde00-0xdeff mem 0xfdaff000-0xfdafffff,0xfdae0000-0xfdaeffff irq 18 at device 0.0 on pci2 > re0: Using 2 MSI messages > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > re0: Ethernet address: 00:1f:d0:8f:5a:43 > re0: [FILTER] > re0: [FILTER] > re0: link state changed to UP > > Here dmesg output when it succeeds: > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet> port 0xde00-0xdeff mem 0xfdaff000-0xfdafffff,0xfdae0000-0xfdaeffff irq 18 at device 0.0 on pci2 > re0: turning off MSI enable bit. > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > re0: Ethernet address: 00:1f:d0:8f:5a:43 > re0: [FILTER] > re0: link state changed to UP > > And here pciconf output: > re0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > It seems that broken controllers have two MSI messages. Instead of reverting the change, how about attached patch? --tEFtbjk+mNEviIIX Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.msi.diff" Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 188426) +++ sys/pci/if_rlreg.h (working copy) @@ -779,7 +779,7 @@ #define RE_RX_DESC_BUFLEN MCLBYTES #endif -#define RL_MSI_MESSAGES 2 +#define RL_MSI_MESSAGES 1 #define RL_ADDR_LO(y) ((uint64_t) (y) & 0xFFFFFFFF) #define RL_ADDR_HI(y) ((uint64_t) (y) >> 32) Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 188426) +++ sys/dev/re/if_re.c (working copy) @@ -1149,7 +1149,8 @@ if (bootverbose) device_printf(dev, "MSI count : %d\n", msic); } - if (msic == RL_MSI_MESSAGES && msi_disable == 0) { + if (msic > 0 && msi_disable == 0) { + msic = 1; if (pci_alloc_msi(dev, &msic) == 0) { if (msic == RL_MSI_MESSAGES) { device_printf(dev, "Using %d MSI messages\n", --tEFtbjk+mNEviIIX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090210005002.GD98095>