From owner-freebsd-current@FreeBSD.ORG Sun Jan 21 17:51:39 2007 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 4602416A405; Sun, 21 Jan 2007 17:51:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id EED3313C474; Sun, 21 Jan 2007 17:51:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l0LHpVGj009348; Sun, 21 Jan 2007 10:51:37 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45B3A821.3060605@samsco.org> Date: Sun, 21 Jan 2007 10:51:29 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0701191055u20b91c84tfabb242c9b6815fd@mail.gmail.com> <200701201041.10752.jhb@freebsd.org> <2a41acea0701201356u53dbbd94m877d4e46615d0b2f@mail.gmail.com> <45B292AB.7050503@samsco.org> <2a41acea0701201410m3ce52c0y7942182b9403037d@mail.gmail.com> In-Reply-To: <2a41acea0701201410m3ce52c0y7942182b9403037d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 21 Jan 2007 10:51:37 -0700 (MST) X-Spam-Status: No, score=-1.2 required=3.8 tests=ALL_TRUSTED, MAILTO_TO_SPAM_ADDR autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Mark Atkinson Subject: Re: another msi blacklist candidate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 17:51:39 -0000 Jack Vogel wrote: > On 1/20/07, Scott Long wrote: >> Jack Vogel wrote: >> > On 1/20/07, John Baldwin wrote: >> >> On Friday 19 January 2007 13:55, Jack Vogel wrote: >> >> > On 1/19/07, Mark Atkinson wrote: >> >> > > I upgraded a box to -current yesterday with the following pci card >> >> in it, >> >> > > (this is the msi disabled verbose boot below) but upon bootup, any >> >> heavy >> >> > > network activity caused watchdog timeouts and resets. Disabling >> >> msi via >> >> > > the two tunables fixed the problem. >> >> > > >> >> > > What info do you need on this problem? >> >> > > >> >> > > found-> vendor=0x8086, dev=0x1076, revid=0x00 >> >> > > bus=4, slot=2, func=0 >> >> > > class=02-00-00, hdrtype=0x00, mfdev=0 >> >> > > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) >> >> > > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), >> >> maxlat=0x00 (0 ns) >> >> > > intpin=a, irq=10 >> >> > > powerspec 2 supports D0 D3 current D0 >> >> > > MSI supports 1 message, 64 bit >> >> > > map[10]: type 1, range 32, base 0xdf9c0000, size 17, >> enabled >> >> > > pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good >> >> > > map[14]: type 1, range 32, base 0xdf9e0000, size 17, >> enabled >> >> > > pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good >> >> > > map[18]: type 4, range 32, base 0xdcc0, size 6, enabled >> >> > > pcib4: requested I/O range 0xdcc0-0xdcff: in range >> >> > > pcib4: matched entry for 4.2.INTA >> >> > > pcib4: slot 2 INTA hardwired to IRQ 18 >> >> > > em0: port >> >> > > 0xdcc0-0xdcff m >> >> > > em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device >> >> 2.0 on pci4 >> >> > > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000 >> >> > > em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 >> >> > > em0: bpf attached >> >> > > em0: Ethernet address: 00:0e:0c:6e:a1:39 >> >> > > em0: [FAST] >> >> > >> >> > Talked about this internally, and the advise here is that the em >> >> driver change >> >> > so that only PCI-E adapters can use MSI, this would eliminate the >> >> need to >> >> > blacklist in the kernel PCI code. >> >> >> >> It's not em(4) that is the problem, but the system, and I'd rather we >> >> fix it >> >> generically rather than in each driver. Maybe we should disable MSI >> >> for non-PCIe >> >> systems? >> > >> > Depends what that means, say a system HAS PCI-E, but also a PCI and/or >> > a PCI-X slot will MSI be unavailable in those slots, that's what I >> would >> > prefer. >> > >> > Jack >> >> Are you saying that MSI should only be available to PCIe devices? That >> will break legitimate PCI-X devices. > > True, the question is how many of those devices are problematic and need > blacklisting anyway? I don't have a feel for this, do you Scott? > > Jack It's up to the driver writers to keep tabs on their peripherals. If the Intel 12345 PCI-X NIC can't do MSI but the Intel 23456 PCI-X NIC can, then it's up to the driver to know that. Chipset support is the responsibility of the OS, and that's where it gets more difficult because MSI is still fairly immature on the x86/x64 platform. Scott